On Sun, 7 May 2006, Joshua Brindle wrote:
> 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.
Yes. This is due to the way connection tracking works, there's no
indication of which connection the packet belongs to, just its state. We
depend on conntrack to correctly determine the state of the packet,
anyway, and we don't have real IP security without something like IPsec.
SELinux policy analysis will need to work on the assumption that conntrack
is working correctly, and that a packet which is a valid part of an ftp
connection won't end up delivering data to sshd.
We could look at something similar to the CONNMARK target, where
connections are labeled, but it's very ugly and really not useful, as we
assume that conntrack is working correctly.
You can always not use conntrack and emulate the existing controls, as
well.
> 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)
The label for the new connection packet is essential for ensuring that the
connection being created is the right type. We know that if a valid SYN
arrives on port 22, that this is an attempt to establish a connection with
sshd (assuming it's configured to listen on port 22). Then, conntrack
observes the TCP handshake, and creates connection state if successful.
Also, we only want sshd to receive new connections here, not create them.
> 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.
See
http://people.redhat.com/jmorris/selinux/secmark/policy/packettest/packettest.te
# Totally insecure, for testing.
#
# Allow all unlabled packets to all domains.
#
allow domain unlabeled_t:packet { send recv };
As the policy is generated by macros, it should be very simple to change
just a few of the macros to generate compatible policy rules for the new
controls.
> 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?
I believe the way to handle this is to create SELinux input and output
chains and then add all of the SELinux labeling rules via them, so the
SELinux rules are at least partitioned off, and these tools will be able
to treat them opaquely. Have a look at the example rulesets I posted on
the web site.
> 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?
It depends on which rule is changed. If it's for a NEW connection, only
packets hitting that will get the new label. For ESTABLISHED & RELATED,
all packets on those rules will get the new label once the rule is
updated.
> Thanks, this will be very beneficial to the SELinux community
I hope so, the SELinux policy should be pretty simple, and the iptables
rules perhaps not so much, but they'll be generated by macros.
I've also seen some interesting performance improvements (especially if
conntrack is not loaded), although we won't really know the overall
picture until all of the current policy is converted over. Then it'll be
a case of how well iptables performs with lots of rules and chains.
- James
--
James Morris
<[EMAIL PROTECTED]>
-
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
