On Wed, 31 May 2006, Chad Hanson wrote: > Based on the first two issues, a logical solution is bring back access control > on nodes and interfaces in a slightly different manner. Prior to the secmark > additions, nodes/interfaces/ports were treated as objects subject to socket > access control. Now that there's a secmark on the packet (skb), the secmark > could be subject to node and interface access. This would enable one to make > sure unclassified data can only be sent to (or received from) the unclassified > node/interface
I'm not sure exactly what you're getting at here, but the whole point of secmark is that you can use _any_ attribute of the packet for labeling, including node, interface, or anything matchable via iptables. So, there's no longer any node or port semantics in SELinux wrt packets, as the selection and labeling phase is entirely performed in iptables. e.g. you can select packets with: port 80 and eth0, and label them as external_httpd_packet_t or, port 80 and eth1 and 10.3.4.0/24 as internal_httpd_packet_t > good example. The secmark mechanism allows only a single label per port, No, it depends on the iptables selectors. The following rules are exclusive: iptables -t mangle -A INPUT -p tcp --dport 80 -i eth0 iptables -t mangle -A INPUT -p tcp --dport 80 -i eth1 and can be labeled distinctly. > PROPOSED IMPLEMENTATION > > On the inbound the packet will default to the unlabeled SID. The packet will > then get labeled per iptables/secmark policy, if any. Next, the packet will > then get checked against the node and interface in new SELinux local_in and > forward netfilter hooks. If this is an IPSec packet, the packet will be > relabeled with the association, overriding the current label. I think we need to keep these labeling mechanisms separate. Secmark is a "local" labeling mechanism, where only attributes of packets are used as selectors. The xfrm labeling is a distributed labeling scheme, where labels on network traffic represent the security contexts of _endpoints_, i.e. domains on different systems which are communicating. Not the packets themselves. This is an important distinction. - James -- James Morris <[EMAIL PROTECTED]> -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
