On Sun, 2006-05-07 at 13:43 -0400, James Morris wrote:
> 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.
>
Something like CONNMARK seems preferable to me (perhaps even allowing
type_transition rules to give the related packets a unique type). This
makes the labeling reflect the real security property of the packets.
Yes, we are trusting the conntrack to mark the packets accurately, but
it makes the policy match the intent. Otherwise it is not possible to
reason about information flow using just the policy.
Are there serious downsides to this approach?
> You can always not use conntrack and emulate the existing controls, as
> well.
>
Yes, but gaining connection tracking is a major advantage of this
approach over the existing controls.
Karl
--
Karl MacMillan
Tresys Technology
www.tresys.com
> > 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]>
>
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to [EMAIL PROTECTED] with
> the words "unsubscribe selinux" without quotes as the message.
-
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
