On Sunday 30 September 2007 3:07:42 pm Theodore Tso wrote:
quoted text
> There are different kinds of security.  Not all of them involve
> cryptography and IPSEC.  Some of them involve armed soldiers and air
> gap firewalls.  :-)
>
> Yes, normally the network is outside the Trusted Computing Base (TCB),
> but a cluster of Linux machines in a rack is roughly the same size of
> a huge Unix server tens year ago --- and it's not like Ethernet is any
> more secure than the PCI bus.  So why do we consider communications
> across a PCI bus secure even though they aren't encrypted?  Why,
> because normally we assume the PCI bus is inside the trust boundary,
> and so we don't worry about bad guys tapping communications between
> the CPU and the hard drive on the PCI bus.
>
> But these days, it is obviously possible to create clusters where
> certain network interfaces are only connected to machines contained
> completely inside the trust boundary, just like a PCI bus in a
> traditional server.  So don't be so quick to dismiss something like
> CIPSO out of hand, just because it doesn't use IPSEC.

Sorry I'm a bit late to the discussion (been busy doing "weekend" things), but 
I see that Casey, Josh, and Ted have already given a pretty good explanation 
of why CIPSO is not as "evil" as it appears at first glance.  I won't restate 
the points they have already made, but I think there are two other points 
worth mentioning:

The first is that CIPSO options are immutable, which means they work 
wonderfully with IPsec.  Label integrity can be provided through the use of 
AH and/or tunneled ESP, label confidentiality can be provided through 
tunneled ESP.  While the SELinux specific labeled IPsec implementation we 
currently have in the kernel is nice if you are talking to other SELinux 
machines, it has a very real handicap in that you can't use it to talk 
anything else.  CIPSO, or CIPSO in combination with standard, non-labeled 
IPsec, can be used to talk to pretty much any trusted OSs out there.  
Adherence to standards and interoperability with other OSs have always been a 
key factor of Linux's acceptance into new areas; support for CIPSO is just 
another part of this drive for greater interoperability.

The second point I wanted to make is that in the course of putting together 
the CIPSO implementation in the kernel I ended up talking with a few people 
who were involved in the original TSIG effort and the mess with the IETF.  
From what I could gather, the main technical complaint (other than a variety 
of political complaints which aren't relevant to our discussion here) was 
that CIPSO options are difficult to parse (they are, look at the format - 
it's an option within an option format - yuck) and the intermediate node 
vendors did not like it all (too much work to do in a fastpath ASIC).  After 
all, look at the [R]IPSO RFC, dated only eight months earlier, and there is 
no cryptographic "special sauce" in that protocol.

CIPSO isn't for everyone, I'll be the first to admit that.  However, if you 
look at the mailing list archive for the Linux LSPP effort, the SELinux list, 
and to a lesser extent the netdev and LSM lists you will see that there are a 
set of users who care very much about this functionality.  Our support of 
CIPSO is helping Linux operate in areas it wouldn't be able to elsewhere and 
I consider that a "win".

-- 
paul moore
linux security @ hp
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/