James Morris wrote:
For example, SELinux will now be able to utilize connection tracking, so
that only packets which are known to be valid for a specific connection
will be allowed to reach the subject.
Sample iptables rules for labeling packets are at:
http://people.redhat.com/jmorris/selinux/secmark/rules/
And examples of new policy controls may be found here:
http://people.redhat.com/jmorris/selinux/secmark/policy/
It looks like you are labeling all packets on an established connection
as tracked_packet_t. What is the rationale for not labeling all ftp
traffic as ftpd_packet_t? Granted that its very unlikely for established
connections to go to the wrong process but the SELinux policy should be
able to clearly show that ftpd and sshd cannot see each others packets
but these policies say that they can both send/receive tracked_packet_t.
Obviously these are just examples, I'm just curious if there was a
reason to label established packets differently from the new connection
packets (and the same as all the other established packets)
I imagine that, at least at first, it would be good to have allow domain
unlabeled_t:packet { send recv }; in an (enabled) conditional so that
the migration will be easier.
Also, we need to come up with a mechanism for distributing default
marking rules that can accompany a policy. The rules could go into a
section in the .pp file but how does that integrate with various
firewall systems that take control of the iptables rules?
And finally, what happens if the labeling rule changes during an
established connection? Do the packets related to that connection retain
the original label or will they get the new label?
Thanks, this will be very beneficial to the SELinux community
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
