Network access controls (resolving xfrm, secmark, and NetLabel)

Network access controls (resolving xfrm, secmark, and NetLabel)

[Paul Moore]

Over on the RedHat LSPP list I have been posting my NetLabel patches (if 
you don't know what they are keep reading) and in the latest round of 
patches it became clear that it is probably worthwhile to have a 
discussion about how to best resolve all of the different network access 
controls.  Stephen suggested this list would be a good place to start so 
here I go.

 From what I gather no one seems to be a big fan of the current network 
access checks in the SELinux code.  They are not very expressive and the 
  recent work to include packet labeling through other methods such as 
IPsec and now NetLabel (CIPSO/RIPSO/etc.) means the SELinux network 
access checks are going to get more and more confusing as more checks 
are added.  I think everybody would like to see the network access 
checks reduced to a single function call.  The question is how.

The IPsec/xfrm controls do all the access control checks at the IP/xfrm 
layer (please correct me if I'm wrong) so checking for access at the 
socket layer where the current LSM hooks are is almost trivial, all you 
have to do is look at a field in the packet to see if the xfrm code 
authorized the packet.

The secmark approach proposed by James a few weeks ago on the netdev 
list labels the packets with a SELinux SID in the IP/netfilter layer and 
checks the SID in the socket layer using the existing LSM hooks.  While 
this is still very much a work in progress the ultimate goal is to 
remove the individual netif/host/port checks in the SELinux code and 
replace them with a single socket/secmark SID access check.  James' 
secmark announcement can be found here:

  * http://marc.theaimsgroup.com/?l=linux-netdev&m=114516429530333&w=2

The NetLabel approach is similar to the secmark approach in that 
NetLabel only attaches/retrieves labels from the network packets and 
lets SELinux perform the access checks.  The immediate goal for NetLabel 
is to provide support for explicit packet labeling protocols such as 
CIPSO/RIPSO.  Also, just recently there has been some interest in using 
NetLabel in a non-SELinux LSM.  The NetLabel patches can be found here:

  * http://free.linux.hp.com/~pmoore/projects/linux_cipso

These are the three approaches (am I missing any?) I think we need to 
resolve.  I also think it would be a good idea if we arrived at a 
solution which abstracts out the actual packet labeling as much as 
possible; this would allow us to add/subtract labeling mechanisms much 
more easily than we can do now.  Further, adding a layer of abstraction, 
if done correctly, would allow other LSMs to utilize the same mechanism 
(I know this may not be very popular here, but I think it would be A 
Good Thing).  Looking at the three approaches above I'm not sure the 
IPsec/xfrm approach is generic enough to support the different types of 
labeling.  This leaves me with either the secmark or the NetLabel approach.

The two approaches, secmark and NetLabel, are very similar and I believe 
quite complimentary.  Further I think it would be rather easy to 
implement either secmark inside of NetLabel or NetLabel inside of 
secmark.  However, of the two I think NetLabel is best suited to 
accommodate both the secmark and IPsec/xfrm access controls.  The 
secmark approach requires the labeling mechanism to live inside the 
netfilter code (correct James?) while the NetLabel approach allows the 
labeling mechanism to happen anywhere it can, in the xfrm transforms, 
netfilter, you name it.  NetLabel also has provisions for labeling 
outgoing packets where I'm not sure secmark does (I didn't think you 
could increase a packet's size in netfilter, can you?).  However, I'll 
be honest in that I'm probably not 100% objective here; I'm just trying 
to start a discussion.

So, anybody else have an opinion?  Come on, I know you do ...

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Network access controls (resolving xfrm, secmark, and NetLabel)

[Brian Sniffen]

Paul Moore <paul.moore@hp.com> writes:

> The secmark approach requires the labeling mechanism to live inside
> the netfilter code (correct James?) while the NetLabel approach
> allows the labeling mechanism to happen anywhere it can, in the xfrm
> transforms, netfilter, you name it.

The sequencing of netfilter makes it very clear how to handle multiple
attempts to apply a label, and very easy to be sure which labels will
be applied to which packets.  With multiple NetLabel points of
contact, how much will you be able to tell statically about the labels
on various sorts of packet?  In how many places will an analyst need
to look?

-Brian

-- 
Brian T. Sniffen                                      bsniffen@mitre.org
The MITRE Corporation                                       781-271-2904

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Network access controls (resolving xfrm, secmark, and NetLabel)

[Paul Moore]

Brian Sniffen wrote:
> Paul Moore <paul.moore@hp.com> writes:
> 
>>The secmark approach requires the labeling mechanism to live inside
>>the netfilter code (correct James?) while the NetLabel approach
>>allows the labeling mechanism to happen anywhere it can, in the xfrm
>>transforms, netfilter, you name it.
> 
> The sequencing of netfilter makes it very clear how to handle multiple
> attempts to apply a label, and very easy to be sure which labels will
> be applied to which packets.  With multiple NetLabel points of
> contact, how much will you be able to tell statically about the labels
> on various sorts of packet?  In how many places will an analyst need
> to look?
> 

If we could do everything in netfilter then I agree with you completely. 
However, I'm not sure that forcing everything to use netfilter is really the 
best solution.  Lets use CIPSO as an example ...

On the incoming side it wouldn't be that difficult to use netfilter and the 
secmark field.  Essentially we would just move the CIPSO IP option validation 
and decoding from their current spots in the IP and socket layers into 
netfilter.  We could argue the merits of such a decision but I believe it would 
work.

The outgoing side would be a bit more difficult.  We would need to create a 
mechanism to set the secmark field on outgoing packets as they leave the 
application (I didn't see this in James patches, please let me know if I missed 
something) and then we would need to add the CIPSO IP option to the packet in 
the netfilter layer, which is the problem.  Assuming it is okay to increase the 
size of the packet in the netfilter layer (I have a nagging memory that I was 
once told this is not allowed, but I can't remember where I heard that) so that 
we could add the CIPSO IP option we are then faced with the following problems:

  * the IP checksum now needs to be recalculated
  * we might not have enough room in the IP header depending on other
    IP options
  * we will most likely run into PMTU problems
  * the IPsec AH transform, if present, is now incorrect

... there are most likely others, these are just the first few that popped into 
my head while typing this.

I think the netfilter/secmark approach is a great improvement for implicit, 
host-generated packet labels but I'm still not convinced it is ideal for 
explicit, dynamic packet labels such as CIPSO.

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Network access controls (resolving xfrm, secmark, and NetLabel)

[Brian Sniffen]

Paul Moore <paul.moore@hp.com> writes:

> If we could do everything in netfilter then I agree with you
> completely. 

Agree with me?  I didn't think I was making a point yet.  I'm just
curious how many degrees of freedom NetLabel has, and what costs will
be borne elsewhere in the system.  From this sort of answer, should I
assume that the costs will be high---but necessary for CIPSO and
similar complexities?

-Brian

-- 
Brian T. Sniffen                                      bsniffen@mitre.org
The MITRE Corporation                                       781-271-2904

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Network access controls (resolving xfrm, secmark, and NetLabel)

[Paul Moore]

Brian Sniffen wrote:
> Paul Moore <paul.moore@hp.com> writes:
>>If we could do everything in netfilter then I agree with you
>>completely. 
> 
> Agree with me?  I didn't think I was making a point yet.

Then perhaps I simply read too much into your mail, although I suspect it 
doesn't matter too much for the discussion at hand.

> I'm just curious how many degrees of freedom NetLabel has, and what costs will
> be borne elsewhere in the system.  From this sort of answer, should I
> assume that the costs will be high---but necessary for CIPSO and
> similar complexities?

I'm assuming when you say "cost" you are talking about the amount of time and 
effort needed to understand the implementation so that a certain level of 
assurance can be reached?  If that is the case, then yes, I believe there is a 
relatively higher cost involved with something like CIPSO due to it's very 
nature.  To some extent NetLabel may inherit some of this cost as a framework 
designed to handle more complex labeling mechanisms.

As for the cost itself, I can only speak in relative terms and only from a 
developer's point of view.  Based on your email address and your presentations I 
suspect you have quite a bit of background in this area; I encourage you to not 
assume to much from my answers here but to look at the patch itself.  Any 
comments you may have about how to increase the ease at which higher levels of 
assurance might be achieved would be very welcome.

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.