[redhat-lspp] [RFC] A Proposal for CIPSO on Linux (again)

[Chris Wright]

* Paul Moore (paul.moore at hp.com) wrote:
> Chris Wright wrote:
> >I guess that's my point.  Using ipsec...so use ipsec ;-)
> 
> Yes, but the nice thing is that if you don't want or need IPsec you 
> don't have to use IPsec.  If you need both data and label integrity as 
> well as data confidentiality and you don't need interoperability with 
> non-Linux hosts than Trent's IPsec extensions are ideal; for everything 
> else CIPSO may present an attractive option to customers.
> 
> Not everyone needs hmacs and encryption to ensure data integrity and 
> confidentiality.

Sure, if you have dedicated private network, or similar guarantees.
IPSec is reasonably flexible (perhaps to a fault), and key exchange
aside, I believe you can make a pretty insecure SA using NULL
algorithms, etc.  But that doesn't address interoperability w/ existing
CIPSO based systems.

> >Yes, I saw that with post_create hook.  But didn't look too far to see
> >that the socket label copied to every fragment, since LSM post_create by
> >itself is not enough.  Nor did I see where you protect from setsockopt
> >to turn it off?  I think the whole idea is harder to show secure, than
> >using ipsec approach.  I also didn't see how you handle raw sockets.
> >
> 
> Can you point to where setting an IP option in the socket does not cause 
> it to be set for every packet (I'm not trying to be atognistic here, I'm 
> just trying to find something I missed - I don't have the extensive 
> Linux stack background that some of you do)?

I believe options handling (on sending) is already coded to cope
with fragments, but that's with standard options.  Actually, looking
at the code, I believe it'd just be in the definition of the option
(i.e. |IPOPT_COPY should do it).  On receipt, I was assuming you'd have to
add something to check each fragment before adding to reassembly queue.
This is a check in a hot path that is bound to be expensive (and not one
that netdev will take lightly at all).  Once you get to sock_rcv_skb
you've lost the options on each fragment packet, because reassembly
processing has already reassembled all the data.

> As far as using 
> setsockopt() to turn it off, why not simply use SELinux to restrict the 
> application from setting socket options?  I would think on a system 
> running CIPSO would want to disallow applications from setting IP level 
> options anyway.  Also, and this should answer your raw socket question 
> as well, the netfilter module would still be able to catch all the 
> packets heading out of the system to ensure they were labeled with the 
> acceptable range.

Yes, using existing hooks can mediate these, I just wanted to point it
out, since your text didn't.

> >>Regarding encapsulation, encapsulation within what?  Another IPv4 
> >>header?  An IPv6 header?
> >
> >Either, really.  But I was thinking of GRE and IP-in-IP type.  Point is,
> >I think doing it right (meaning can't undermine the protection) is what
> >requires more invasive hooks.
> 
> All right, your correct in that it probably shouldn't matter but is 
> exporting the label to the outermost protocol really what you want to 
> do?  For instance, CIPSO isn't really even defined for IPv6 (although it 
> appears some OSs do support it, I haven't seen a packet dump yet but I 
> suspect it is through destination options).

You certainly want the innermost since that's where the actual payload is.
But, you probably want both to make sure the outer tunnel can't be used
to bypass checks.  I don't know the right answer, but it's another area
where you may have to hook.

> >This is the only compelling reasoning, but it's not technical, and I
> >think the technical issues outweigh here.  The problem is the performance
> >hit is felt too far and wide.  This is processing that has to happen on
> >every outbound and inbound packet.  Inbound is certainly helped since
> >we have security_sock_rcv_skb.
> 
> Interoperability I think is a *very* compelling reason, heck, it is the 
> only reason I bothered to spend some time and see if I could come up 
> with a way to maybe make CIPSO work.

Understood.  Problem is, it's impossible to sell this as 'non-niche'
technology.  And if it hurts mainline, it will simply not fly.

> I think the IPsec extensions offer 
> a lot, and it would be great if some day the other big MLS OSs supported 
> the IPsec extensions.  However, that is not the case today and I think 
> we need a option that can work alongside existing MLS solutions.

I see the need, I just haven't been convinced that this can be done in a
way that will be acceptable upstream.  At which point, it's a custom
hack, and you should do whatever you like ;-)

> Regarding performance, I just don't get your argument.  Currently the 
> only alternative we have is IPsec and I am pretty confident that a CIPSO 
> implementation can be made to have less overhead than IPsec, even using 
> just AH and a fast hash algorithm.

No, that's not what I mean.  CIPSO vs. IPSec is irrelevant.  It's
current mainline (no packet labelling) vs. mainline w/ packet labelling.
If adding packet labelling has a negative performance impact on users
who don't require (or even remotely care about) packet labelling, it's a
non-starter.  Inbound packet processing is highly optimized, and it's
easy to make large regressions with small changes.

> >>Also, please keep in mind that my CIPSO proposal and Trent's IPsec 
> >>approach are not mutually exclusive.  Both can co-exist in a running 
> >>kernel.
> > 
> >*nod*
> 
> At least we can agree on something ;)

Heh ;-)

thanks,
-chris