AF_VSOCK and the LSMs

AF_VSOCK and the LSMs

[Paul Moore]

With AF_VSOCK now in the next tree I've started looking at what we would need 
to do to add the appropriate LSM hooks so that AF_VSOCK traffic can be 
controlled just as we do with other protocols.  The reasons why are pretty 
simple, those users who rely on LSMs to help enforce separation between VMs 
want to be able to ensure that the separation extends down to this new method 
of communication, especially considering it provides a mechanism for 
communication between VMs.

Looking at AF_VSOCK, and the underlying VMCI transport (currently the only 
transport option), it looks fairly similar to AF_INET, at least it is much 
similar to AF_INET than it is to AF_UNIX.  With that in mind, taking an 
approach similar to what we currently do for AF_INET should make the necessary 
LSM kernel changes smaller and the related, LSM-specific security policy more 
approachable to those already familiar with the LSM's network access controls.

Perhaps the biggest different between the current AF_VSOCK/VMCI combination 
and AF_INET is the lack of labeling support at the transport layer.  Basically 
the labeling in AF_INET, via protocols that leverage IP, allow the sender to 
tag traffic with a security label that can be used to perform access control 
on receipt of the traffic.  Since AF_VSOCK traffic sent over the VMCI 
transport does not carry any LSM related information about the sender we are 
not able to do the same level of access control.  However, if we were to 
augment the current VMCI tranport to tag traffic with the security label of 
the sender we could start doing proper LSM based access control with AF_VSOCK 
traffic.

I'm currently working on a set of patches to do just that, but before I get 
too far down this path, I thought I would toss this out to the various lists 
to see if anyone had any strong feelings on this approach (either good or 
bad).  Here is what I am proposing, and currently working on ...

* Add a LSM secid/blob to the vmci_datagram struct

First some background on LSM stacking: there is a lot of work going on to look 
at stacking different LSMs (currently it is a one-at-a-time system) but 
unfortunately due to a lack of a proper security blob (e.g. we would need a 
security void pointer in the sk_buff) it is unlikely that we will be able to 
stack LSMs which use network labels anytime soon.  With that in mind, while 
some on the LSM list would likely argue for a security blob being added to 
struct vmci_datagram I think the easiest solution for the time being is to 
just add a secid field (a single u32 scalar); true it is probably not ideal 
but it simplifies the management of the field considerably and is no worse 
than what we currently have for AF_INET[6].  In the future we could always add 
a proper LSM blob if needed as this is internal and private to the kernel.

With the background out of the way, adding a LSM secid/blob to struct 
vmci_datagram would allow us to convey the sending socket's LSM label with the 
rest of the VMCI datagram/packet to the receiving socket where we could 
perform a LSM access check using the sender and receiver's LSM labels.  Once 
again, this is very similar to what we currently do with AF_INET[6].

In order to do this we would need to make some changes to a few functions, 
mostly just to ensure we have access to the necessary socket labels when 
needed:

  - vmci_transport_send_control_pkt()
  - vmci_transport_reply_control_pkt_fast() / vmci_transport_reply_reset()
  - vmci_transport_send_control_pkt_bh() / *notify_pkt() handler
  - vmci_tansport_send_control_pkt()

This may not be a complete list, and I'm being vague on the actual changes as 
this is currently a work in progress ...

* Add LSM hooks to vmci_transport_recv_{dgram,stream}_cb()

In both cases we would probably want the LSM access control hook/check to 
occur just after the call to vmci_transport_allow_dgram().  While I haven't 
gotten to this part of the patchset yet, I expect the LSM hook to look very 
similar to the existing security_sock_rcv_skb() hook; in fact, I hope to just 
reuse the existing hook but we will have to see how things develop.

* Add LSM hooks to vmci_transport_recv_connecting_{client,server}()

This isn't so much an access control point, that is handled above, but rather 
a notification for the LSM that the negotiation has finished and the sockets 
are connected.  This notification allows the LSM to update any internal state, 
e.g. the socket's peer labels.

* Update the SELinux and Smack LSMs to support the AF_VSOCK address family

Essentially this means just making sure that the socket level access controls, 
and perhaps some of the packet level controls if reused, understand the 
AF_VSOCK family and do the right thing.  For Smack this should be rather 
trivial, for SELinux it will be slightly more involved but still rather simple 
and straightforward (perhaps add a new "virt_socket" object class).

The other LSMs, TOMOYO and AppArmor, handle their network access controls 
differently and as a result, I believe there is no work needed for these LSMs 
but I would encourage the TOMOYO and AppArmor devs to correct me if I missed 
anything.

-- 
paul moore
security and virtualization @ redhat


--
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: AF_VSOCK and the LSMs

[Casey Schaufler]

On 2/22/2013 2:33 PM, Paul Moore wrote:
> With AF_VSOCK now in the next tree I've started looking at what we would need 
> to do to add the appropriate LSM hooks so that AF_VSOCK traffic can be 
> controlled just as we do with other protocols.  The reasons why are pretty 
> simple, those users who rely on LSMs to help enforce separation between VMs 
> want to be able to ensure that the separation extends down to this new method 
> of communication, especially considering it provides a mechanism for 
> communication between VMs.
>
> Looking at AF_VSOCK, and the underlying VMCI transport (currently the only 
> transport option), it looks fairly similar to AF_INET, at least it is much 
> similar to AF_INET than it is to AF_UNIX.  With that in mind, taking an 
> approach similar to what we currently do for AF_INET should make the necessary 
> LSM kernel changes smaller and the related, LSM-specific security policy more 
> approachable to those already familiar with the LSM's network access controls.
>
> Perhaps the biggest different between the current AF_VSOCK/VMCI combination 
> and AF_INET is the lack of labeling support at the transport layer.  Basically 
> the labeling in AF_INET, via protocols that leverage IP, allow the sender to 
> tag traffic with a security label that can be used to perform access control 
> on receipt of the traffic.  Since AF_VSOCK traffic sent over the VMCI 
> transport does not carry any LSM related information about the sender we are 
> not able to do the same level of access control.  However, if we were to 
> augment the current VMCI tranport to tag traffic with the security label of 
> the sender we could start doing proper LSM based access control with AF_VSOCK 
> traffic.
>
> I'm currently working on a set of patches to do just that, but before I get 
> too far down this path, I thought I would toss this out to the various lists 
> to see if anyone had any strong feelings on this approach (either good or 
> bad).  Here is what I am proposing, and currently working on ...
>
> * Add a LSM secid/blob to the vmci_datagram struct

Please add an LSM blob. Please do not use a secid. I am currently
battling with secids in my efforts for multiple LSM support.

> First some background on LSM stacking: there is a lot of work going on to look 
> at stacking different LSMs (currently it is a one-at-a-time system) but 
> unfortunately due to a lack of a proper security blob (e.g. we would need a 
> security void pointer in the sk_buff) it is unlikely that we will be able to 
> stack LSMs which use network labels anytime soon.  With that in mind, while 
> some on the LSM list would likely argue for a security blob being added to 
> struct vmci_datagram I think the easiest solution for the time being is to 
> just add a secid field (a single u32 scalar); true it is probably not ideal 
> but it simplifies the management of the field considerably and is no worse 
> than what we currently have for AF_INET[6].  In the future we could always add 
> a proper LSM blob if needed as this is internal and private to the kernel.

Please! No secids!

I am going to be able to deal with secids for AF_INET only because 
SELinux prefers XFRM, Smack requires CIPSO, and AppArmor is going to
be willing to have networking be optional.

If you have two LSMs that use secids you are never going to have a
rational way to get the information for both into one secid.

>
> With the background out of the way, adding a LSM secid/blob to struct 
> vmci_datagram would allow us to convey the sending socket's LSM label with the 
> rest of the VMCI datagram/packet to the receiving socket where we could 
> perform a LSM access check using the sender and receiver's LSM labels.  Once 
> again, this is very similar to what we currently do with AF_INET[6].
>
> In order to do this we would need to make some changes to a few functions, 
> mostly just to ensure we have access to the necessary socket labels when 
> needed:
>
>   - vmci_transport_send_control_pkt()
>   - vmci_transport_reply_control_pkt_fast() / vmci_transport_reply_reset()
>   - vmci_transport_send_control_pkt_bh() / *notify_pkt() handler
>   - vmci_tansport_send_control_pkt()
>
> This may not be a complete list, and I'm being vague on the actual changes as 
> this is currently a work in progress ...
>
> * Add LSM hooks to vmci_transport_recv_{dgram,stream}_cb()
>
> In both cases we would probably want the LSM access control hook/check to 
> occur just after the call to vmci_transport_allow_dgram().  While I haven't 
> gotten to this part of the patchset yet, I expect the LSM hook to look very 
> similar to the existing security_sock_rcv_skb() hook; in fact, I hope to just 
> reuse the existing hook but we will have to see how things develop.
>
> * Add LSM hooks to vmci_transport_recv_connecting_{client,server}()
>
> This isn't so much an access control point, that is handled above, but rather 
> a notification for the LSM that the negotiation has finished and the sockets 
> are connected.  This notification allows the LSM to update any internal state, 
> e.g. the socket's peer labels.
>
> * Update the SELinux and Smack LSMs to support the AF_VSOCK address family
>
> Essentially this means just making sure that the socket level access controls, 
> and perhaps some of the packet level controls if reused, understand the 
> AF_VSOCK family and do the right thing.  For Smack this should be rather 
> trivial, for SELinux it will be slightly more involved but still rather simple 
> and straightforward (perhaps add a new "virt_socket" object class).
>
> The other LSMs, TOMOYO and AppArmor, handle their network access controls 
> differently and as a result, I believe there is no work needed for these LSMs 
> but I would encourage the TOMOYO and AppArmor devs to correct me if I missed 
> anything.
>


--
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: AF_VSOCK and the LSMs

[Paul Moore]

On Friday, February 22, 2013 02:54:43 PM Andy King wrote:
> Hi Paul,
> 
> > to see if anyone had any strong feelings on this approach (either good or
> > bad).  Here is what I am proposing, and currently working on ...
> > 
> > * Add a LSM secid/blob to the vmci_datagram struct
> 
> I think perhaps this is the wrong layer at which to embed this.  Think
> of that structure as an ethernet header, with VMCI being ethernet; it's
> what the device (and the hypervisor and peer) understand.  So this
> really cannot be changed.

Hmmm, so can VMware/VMCI-enabled guests send vmci_datagram packets directly 
into the kernel?  It isn't wrapped by things like AF_VSOCK?  If that is the 
case, then yes, we'll probably need to add a thin wrapper struct to carry the 
security label; similar to the control packets but not quite, as we have data 
to deal with unlike the control packets.  However, if vmci_datagram is an 
internal only structure, why not add the extra field?

Either way, we should be able to work around this, it would just be cleaner if 
we could add it to the datagram directly.

> It's also not entirely clear to me how this will work in a heterogeneous
> environments.  What if there's a Linux guest running on a Windows host,
> or vice-versa?

I maybe missing something here, but VMCI never leaves the physical host system 
correct?  It doesn't get tunneled over some external network does it?

Assuming it stays on the physical host system then we don't really care about 
a Windows host in this context do we?  From a guests point of view it doesn't 
really matter, the kernel handles all of the labeling and access control; the 
guests create their AF_VSOCKS as they normally would.

> I'll take a closer read at the rest of your mail, but I think we need to
> address the above first.

I think there is some confusion about VMCI - which is almost surely on my end 
- and what I'm trying to accomplish with the labeling, perhaps by answering 
the above questions you can help me gain a better understanding and we can 
sort things out.

Thanks.

-- 
paul moore
security and virtualization @ redhat


--
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: AF_VSOCK and the LSMs

[Paul Moore]

On Friday, February 22, 2013 03:00:04 PM Casey Schaufler wrote:
> Please add an LSM blob. Please do not use a secid. I am currently
> battling with secids in my efforts for multiple LSM support.
>
> ...
> 
> I am going to be able to deal with secids for AF_INET only because
> SELinux prefers XFRM, Smack requires CIPSO, and AppArmor is going to
> be willing to have networking be optional.

"prefers"?  Really Casey, did you think I would let you get away with that 
statement?  What a LSM "prefers" is really not relevant to the stacking 
effort, what a LSM _supports_ is what matters.

SELinux _supports_ NetLabel (CIPSO, etc.), XFRM (labeled IPsec), and secmark.

Smack _supports_ NetLabel (CIPSO).

AppArmor and TOMOYO don't really do any of the forms of labeled networking 
that are relevant for this discussion.  If you are going to do stacking with 
LSMs that conflict when it comes to what they _support_, not what they 
_prefer_, with labeled networking then you are either going to have to either:

1. Selectively remove support from all but one of the LSMs. (ungh ...)
2. Convince netdev to give you a blob in the sk_buff. (the pigs are flying!)
3. Work some sub-system dependent magic.

If you want to try option #3 I think we might be able to do something with 
NetLabel to support multiple LSMs as the label abstraction stuff should 
theoretically make this possible; although the NetLabel cache will need some 
work.  Labeled IPsec is likely out due to the way it was designed unless you 
want to attempt to negotiate two labels during the IKE exchange (yuck).  I 
think we can also rule out secmark as multi-LSM enabled due to the limitations 
on a 32 bit integer.

If you want to talk about this further let me know - I think we've talked 
about this at the past two security summits - but don't attempt to gloss over 
details with this "prefers" crap.

> If you have two LSMs that use secids you are never going to have a
> rational way to get the information for both into one secid.

Exactly, I don't disagree which is why I've always said that networking was 
going to be a major problem for the stacked LSM effort.  Unfortunately it 
sounds like you haven't yet made any serious effort into resolving that 
problem other than saying "don't do that".

Now, circling back to the issue of secid/blob in the AF_VSOCK/VMCI context ... 
based on Andy's email I think I'm still missing some critical bit of 
understanding regarding how VMCI is used so let's punt on this for a moment; 
however, your preference for a blob is noted (you also remember that I prefer 
blobs when they make sense, reference a lot of our earlier discussions).

-- 
paul moore
security and virtualization @ redhat


--
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: AF_VSOCK and the LSMs

[Casey Schaufler]

On 2/22/2013 4:45 PM, Paul Moore wrote:
> On Friday, February 22, 2013 03:00:04 PM Casey Schaufler wrote:
>> Please add an LSM blob. Please do not use a secid. I am currently
>> battling with secids in my efforts for multiple LSM support.
>>
>> ...
>>
>> I am going to be able to deal with secids for AF_INET only because
>> SELinux prefers XFRM, Smack requires CIPSO, and AppArmor is going to
>> be willing to have networking be optional.
> "prefers"?  Really Casey, did you think I would let you get away with that 
> statement?  What a LSM "prefers" is really not relevant to the stacking 
> effort, what a LSM _supports_ is what matters.

I suppose. My point, which you may refute if it is incorrect,
is that there are common, legitimate SELinux configurations which
eschew Netlabel in favor of XFRM.

> SELinux _supports_ NetLabel (CIPSO, etc.), XFRM (labeled IPsec), and secmark.
>
> Smack _supports_ NetLabel (CIPSO).
>
> AppArmor and TOMOYO don't really do any of the forms of labeled networking 
> that are relevant for this discussion.

I am informed that labeled networking is being developed as an
option for AppArmor.

> If you are going to do stacking with 
> LSMs that conflict when it comes to what they _support_, not what they 
> _prefer_, with labeled networking then you are either going to have to either:
>
> 1. Selectively remove support from all but one of the LSMs. (ungh ...)
> 2. Convince netdev to give you a blob in the sk_buff. (the pigs are flying!)
> 3. Work some sub-system dependent magic.

With those being the possibilities, the choice is pretty obvious.
(It's 3, just in case the reader is unfamiliar with the histories
involved)

> If you want to try option #3 I think we might be able to do something with 
> NetLabel to support multiple LSMs as the label abstraction stuff should 
> theoretically make this possible; although the NetLabel cache will need some 
> work.

It is reasonably easy to restrict Netlabel to a single LSM,
and since SELinux seems better served by XFRM in most configurations
and AppArmor intends to make networking an option that seems
like a viable strategy until Netlabel gets multiple LSM support.

> Labeled IPsec is likely out due to the way it was designed unless you 
> want to attempt to negotiate two labels during the IKE exchange (yuck).  I 
> think we can also rule out secmark as multi-LSM enabled due to the limitations 
> on a 32 bit integer.

That was my take as well. But, since only SELinux uses those currently,
and I see little pressure for Smack to support them I don't have
a lot of incentive in that direction.

> If you want to talk about this further let me know - I think we've talked 
> about this at the past two security summits - but don't attempt to gloss over 
> details with this "prefers" crap.

Sorry if I presented my position poorly. I'm not trying to
gloss over details, and I apologize if I gave offense or made
statements that disrupted the harmony of the community.

>
>> If you have two LSMs that use secids you are never going to have a
>> rational way to get the information for both into one secid.
> Exactly, I don't disagree which is why I've always said that networking was 
> going to be a major problem for the stacked LSM effort.  Unfortunately it 
> sounds like you haven't yet made any serious effort into resolving that 
> problem other than saying "don't do that".

Oh believe me, I have made serious effort. I just haven't made
significant progress. The good news is that there can be a
networking configuration (SELinux with XFRM, Smack with Netlabel,
AppArmor with none) that is both supported and rational.

Options I have considered include:
	- Netlabel support for discriminating LSM use by host,
	  just as it currently allows for unlabeled hosts.
	- Netlabel as an independent LSM. Lots of refactoring.
	- secid maps.
	- Remove secids completely in favor of blobs.

I should have an updated patch set by month's end. I think it
will address the current LSM issues. I don't know that I can
say it will address everything new LSMs might want to try.

> Now, circling back to the issue of secid/blob in the AF_VSOCK/VMCI context ... 
> based on Andy's email I think I'm still missing some critical bit of 
> understanding regarding how VMCI is used so let's punt on this for a moment; 
> however, your preference for a blob is noted (you also remember that I prefer 
> blobs when they make sense, reference a lot of our earlier discussions).

Indeed. Thank you. A blob can contain sub-blobs. A secid is just
a number at the whim of an LSM.

Thanks. Sorry 'bout the whole "prefer" bruhaha.


--
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: AF_VSOCK and the LSMs

[Paul Moore]

On Monday, February 25, 2013 08:29:46 AM Gerd Hoffmann wrote:
>   Hi,

Hello.

> >> I think perhaps this is the wrong layer at which to embed this.  Think
> >> of that structure as an ethernet header, with VMCI being ethernet; it's
> >> what the device (and the hypervisor and peer) understand.  So this
> >> really cannot be changed.
> > 
> > Hmmm, so can VMware/VMCI-enabled guests send vmci_datagram packets
> > directly into the kernel?  It isn't wrapped by things like AF_VSOCK? If
> > that is the case, then yes, we'll probably need to add a thin wrapper
> > struct to carry the security label; similar to the control packets but not
> > quite, as we have data to deal with unlike the control packets.  However,
> > if vmci_datagram is an internal only structure, why not add the extra
> > field?
> 
> vmci_datagram is part of the guest/host ABI I think.
> 
> Data flow looks like this:
> 
> (1) guest application opens a AF_VSOCK socket
> (2) guest sends data as usual (say send syscall).
> (3) vsock core hards over the packet to the transport layer
> 
>     (only vmci atm, but we wanna add virtio here).
> 
> (4) transport layer passes data to the hypervisor (vmci uses a
> 
>     virtual pci device for that, virtio will do the same).
> ...

Okay, I think I found the core of my misunderstanding: I was under the 
impression that the AF_VSOCK layer lived in the host kernel, not the guest 
kernel.

With the VS_VSOCK layer in the guest kernel this all becomes much less 
interesting.  I'll take another look today, but I think the only changes we 
probably want to make are with SELinux - the "virt_socket" object class - so 
we can control which applications in the guest can use AF_VSOCK sockets.  I 
don't think we will need any changes to Smack but I'll take a closer look.  
Also, all the changes I suggested earlier to VMCI aren't necessary; as you and 
Andy point out, this is the wrong layer - we can't do a whole lot of 
meaningful enforcement in the guest.

Thanks for the clarification.
-Paul

-- 
paul moore
security and virtualization @ redhat


--
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: AF_VSOCK and the LSMs

[Paul Moore]

[NOTE/WARNING: we're veering away from the VSOCK discussion and towards a LSM 
stacking discussion; see my response to Gerd if you want to stay on topic.]

On Saturday, February 23, 2013 03:43:23 PM Casey Schaufler wrote:
> On 2/22/2013 4:45 PM, Paul Moore wrote:
> > On Friday, February 22, 2013 03:00:04 PM Casey Schaufler wrote:
> >> Please add an LSM blob. Please do not use a secid. I am currently
> >> battling with secids in my efforts for multiple LSM support.
> >> 
> >> ...
> >> 
> >> I am going to be able to deal with secids for AF_INET only because
> >> SELinux prefers XFRM, Smack requires CIPSO, and AppArmor is going to
> >> be willing to have networking be optional.
> > 
> > "prefers"?  Really Casey, did you think I would let you get away with that
> > statement?  What a LSM "prefers" is really not relevant to the stacking
> > effort, what a LSM _supports_ is what matters.
> 
> I suppose. My point, which you may refute if it is incorrect,
> is that there are common, legitimate SELinux configurations which
> eschew Netlabel in favor of XFRM.

There are common, legitimate use cases which use exclusively NetLabel, 
exclusively labeled IPsec, and both.  A LSM stacking design that forces 
SELinux to only operate with XFRM (labeled IPsec) is wrong.  If you are giving 
admins the ability to selectively stack LSMs you should also allow them to 
selectively pick which non-shareable functionality they assign to each LSM.

> > SELinux _supports_ NetLabel (CIPSO, etc.), XFRM (labeled IPsec), and
> > secmark.
> > 
> > Smack _supports_ NetLabel (CIPSO).
> > 
> > AppArmor and TOMOYO don't really do any of the forms of labeled networking
> > that are relevant for this discussion.
> 
> I am informed that labeled networking is being developed as an
> option for AppArmor.

I've remember hearing the same several years ago too, until we see patches it 
doesn't make sense to spend a lot of time worrying about what the AppArmor 
developers plan to support.  Regardless, if anything I think this only 
furthers the need to provide a mechanism to selectively assign non-shareable 
LSM functionality to individuals LSMs in a stacked scenario.
 
> > If you want to try option #3 I think we might be able to do something with
> > NetLabel to support multiple LSMs as the label abstraction stuff should
> > theoretically make this possible; although the NetLabel cache will need
> > some work.
> 
> It is reasonably easy to restrict Netlabel to a single LSM,
> and since SELinux seems better served by XFRM in most configurations ...

I disagree.  In some use cases SELinux is better served by XFRM, in others it 
is better served by NetLabel.  Once again, I think you need to focus on what 
is possible with the LSMs rather than a particular set of use cases which 
happen to make the LSM stacking project easier.

> and AppArmor intends to make networking an option that seems
> like a viable strategy until Netlabel gets multiple LSM support.

It would be nice if the AppArmor developers could share their plans - or have 
I missed them on the list?  My apologies if that is the case, a pointer would 
be helpful ...

> > Labeled IPsec is likely out due to the way it was designed unless you
> > want to attempt to negotiate two labels during the IKE exchange (yuck).  I
> > think we can also rule out secmark as multi-LSM enabled due to the
> > limitations on a 32 bit integer.
> 
> That was my take as well. But, since only SELinux uses those currently,
> and I see little pressure for Smack to support them I don't have
> a lot of incentive in that direction.

Agreed.

> >> If you have two LSMs that use secids you are never going to have a
> >> rational way to get the information for both into one secid.
> > 
> > Exactly, I don't disagree which is why I've always said that networking
> > was going to be a major problem for the stacked LSM effort.  Unfortunately
> > it sounds like you haven't yet made any serious effort into resolving that
> > problem other than saying "don't do that".
> 
> Oh believe me, I have made serious effort. I just haven't made
> significant progress.

True, that wasn't a fair comment for me to make - my apologies.

> The good news is that there can be a networking configuration (SELinux with
> XFRM, Smack with Netlabel, AppArmor with none) that is both supported and
> rational.

I disagree that the approach you are proposing is the one that should be 
adopted.  I am very much in favor of providing the ability to selectively 
assign non-shareable LSM features when stacking.  If you aren't able to create 
a mechanism to assign features when stacking, I think I would be more in favor 
of a "first come, first served" model (the first LSM gets whatever it wants, 
and each LSM stacked on top has to make do with what is left) over what you 
are currently proposing.

> Options I have considered include:
> 	- Netlabel support for discriminating LSM use by host,
> 	  just as it currently allows for unlabeled hosts.

Hmm, interesting ... not sure what I think of this.

> 	- Netlabel as an independent LSM. Lots of refactoring.

Ungh, no.

> 	- secid maps.

Can you elaborate on this?  I can think of a few different meanings here ...

> 	- Remove secids completely in favor of blobs.

Obviously ideal, but unlikely to happen unless the netdev crew change their 
mind on blobs in sk_buff.

> I should have an updated patch set by month's end. I think it
> will address the current LSM issues. I don't know that I can
> say it will address everything new LSMs might want to try.

I'll be sure to take a closer look then.  I should have taken a closer look at 
your previous patches - my mistake and I'll take responsibility for that - but 
based on the discussion from the last security summit I was under the 
impression that stacking was only going to be allowed between "big" and 
"little" LSMs, that is obviously no longer the case.

-- 
paul moore
security and virtualization @ redhat


--
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: AF_VSOCK and the LSMs

[Casey Schaufler]

On 2/25/2013 8:55 AM, Paul Moore wrote:
> [NOTE/WARNING: we're veering away from the VSOCK discussion and towards a LSM 
> stacking discussion; see my response to Gerd if you want to stay on topic.]
>
> On Saturday, February 23, 2013 03:43:23 PM Casey Schaufler wrote:
>> On 2/22/2013 4:45 PM, Paul Moore wrote:
>>> On Friday, February 22, 2013 03:00:04 PM Casey Schaufler wrote:
>>>> Please add an LSM blob. Please do not use a secid. I am currently
>>>> battling with secids in my efforts for multiple LSM support.
>>>>
>>>> ...
>>>>
>>>> I am going to be able to deal with secids for AF_INET only because
>>>> SELinux prefers XFRM, Smack requires CIPSO, and AppArmor is going to
>>>> be willing to have networking be optional.
>>> "prefers"?  Really Casey, did you think I would let you get away with that
>>> statement?  What a LSM "prefers" is really not relevant to the stacking
>>> effort, what a LSM _supports_ is what matters.
>> I suppose. My point, which you may refute if it is incorrect,
>> is that there are common, legitimate SELinux configurations which
>> eschew Netlabel in favor of XFRM.
> There are common, legitimate use cases which use exclusively NetLabel, 
> exclusively labeled IPsec, and both.  A LSM stacking design that forces 
> SELinux to only operate with XFRM (labeled IPsec) is wrong.  If you are giving 
> admins the ability to selectively stack LSMs you should also allow them to 
> selectively pick which non-shareable functionality they assign to each LSM.

That is the approach I'm taking. The kernel configuration
will specify which LSM gets Netlabel and which gets XFRM.

A Smack configuration that does not use Netlabel is possible,
but to my mind extremely uninteresting. If someone has a
use case that is best addressed using both Smack and SELinux*
it seems that the most likely configuration would be for
Smack to use Netlabel and SELinux XFRM.

------
* What that case might be is not something I'm especially keen
  on considering in depth just now.
 

>>> SELinux _supports_ NetLabel (CIPSO, etc.), XFRM (labeled IPsec), and
>>> secmark.
>>>
>>> Smack _supports_ NetLabel (CIPSO).
>>>
>>> AppArmor and TOMOYO don't really do any of the forms of labeled networking
>>> that are relevant for this discussion.
>> I am informed that labeled networking is being developed as an
>> option for AppArmor.
> I've remember hearing the same several years ago too, until we see patches it 
> doesn't make sense to spend a lot of time worrying about what the AppArmor 
> developers plan to support.  Regardless, if anything I think this only 
> furthers the need to provide a mechanism to selectively assign non-shareable 
> LSM functionality to individuals LSMs in a stacked scenario.

I have not seen patches, but as Smack+AppArmor and SELinux+AppArmor are
included in my success criteria for module stacking I have to keep the
plan in mind. BTW, Smack+SELinux is not a success criteria, but it would
sure feel good to be able to claim total victory.


>>> If you want to try option #3 I think we might be able to do something with
>>> NetLabel to support multiple LSMs as the label abstraction stuff should
>>> theoretically make this possible; although the NetLabel cache will need
>>> some work.
>> It is reasonably easy to restrict Netlabel to a single LSM,
>> and since SELinux seems better served by XFRM in most configurations ...
> I disagree.  In some use cases SELinux is better served by XFRM, in others it 
> is better served by NetLabel.  Once again, I think you need to focus on what 
> is possible with the LSMs rather than a particular set of use cases which 
> happen to make the LSM stacking project easier.

I'm trying not to make too many architectural changes to the
code around the LSM mechanism itself. I don't see that as cost
effective or likely to be popular. If the implication of that is
that there are certain configurations that are unsupportable but
that have plausible alternatives I think it will do for phase I.

If you want SELinux using Netlabel and Smack using Netlabel at
the same time you're going to have to change something. That
might well involve reimplementing Smack in SELinux policy*,
switching SELinux to XFRM if that's reasonable or using other
mechanisms like containers. It's not like we have a shortage
of mechanisms available.

-----
* I'm still waiting to see this. It was only supposed to take
  a couple days. :-)

>> and AppArmor intends to make networking an option that seems
>> like a viable strategy until Netlabel gets multiple LSM support.
> It would be nice if the AppArmor developers could share their plans - or have 
> I missed them on the list?  My apologies if that is the case, a pointer would 
> be helpful ...

Agreed. I understand that priorities shift like sands
in the desert.


>>> Labeled IPsec is likely out due to the way it was designed unless you
>>> want to attempt to negotiate two labels during the IKE exchange (yuck).  I
>>> think we can also rule out secmark as multi-LSM enabled due to the
>>> limitations on a 32 bit integer.
>> That was my take as well. But, since only SELinux uses those currently,
>> and I see little pressure for Smack to support them I don't have
>> a lot of incentive in that direction.
> Agreed.
>
>>>> If you have two LSMs that use secids you are never going to have a
>>>> rational way to get the information for both into one secid.
>>> Exactly, I don't disagree which is why I've always said that networking
>>> was going to be a major problem for the stacked LSM effort.  Unfortunately
>>> it sounds like you haven't yet made any serious effort into resolving that
>>> problem other than saying "don't do that".
>> Oh believe me, I have made serious effort. I just haven't made
>> significant progress.
> True, that wasn't a fair comment for me to make - my apologies.
>
>> The good news is that there can be a networking configuration (SELinux with
>> XFRM, Smack with Netlabel, AppArmor with none) that is both supported and
>> rational.
> I disagree that the approach you are proposing is the one that should be 
> adopted.  I am very much in favor of providing the ability to selectively 
> assign non-shareable LSM features when stacking.  If you aren't able to create 
> a mechanism to assign features when stacking, I think I would be more in favor 
> of a "first come, first served" model (the first LSM gets whatever it wants, 
> and each LSM stacked on top has to make do with what is left) over what you 
> are currently proposing.

Yeah, you have to give people rope. The Kconfig files can suggest
something rational, but in the end people do the darnedest things.
Especially with security.

>> Options I have considered include:
>> 	- Netlabel support for discriminating LSM use by host,
>> 	  just as it currently allows for unlabeled hosts.
> Hmm, interesting ... not sure what I think of this.

It breaks down on 127.0.0.1. Otherwise is looks pretty easy to do.

>> 	- Netlabel as an independent LSM. Lots of refactoring.
> Ungh, no.

4am, five time zones from home and hungover. The write-up looked
good, but it's a complete rewrite.

>> 	- secid maps.
> Can you elaborate on this?  I can think of a few different meanings here ...

This fell out of my first shot at stacking, the one that never saw
the light of day for tax reasons. I had implemented a stacker LSM
that slid into the existing infrastructure. Hooks that asked for
secids got the secid from my LSM, not the underlying LSM secids.
There was a table much like the Smack label list that mapped the
global secids to sets of underlying secids. The obvious problem
is that that table grows quickly and can never go away.


>> 	- Remove secids completely in favor of blobs.
> Obviously ideal, but unlikely to happen unless the netdev crew change their 
> mind on blobs in sk_buff.
>
>> I should have an updated patch set by month's end. I think it
>> will address the current LSM issues. I don't know that I can
>> say it will address everything new LSMs might want to try.
> I'll be sure to take a closer look then.  I should have taken a closer look at 
> your previous patches - my mistake and I'll take responsibility for that - but 
> based on the discussion from the last security summit I was under the 
> impression that stacking was only going to be allowed between "big" and 
> "little" LSMs, that is obviously no longer the case.

It seemed like that would be a reasonable approach until AppArmor
started looking like a "big" LSM.


--
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: AF_VSOCK and the LSMs

[Paul Moore]

On Monday, February 25, 2013 10:02:42 AM Casey Schaufler wrote:
> On 2/25/2013 8:55 AM, Paul Moore wrote:
> > [NOTE/WARNING: we're veering away from the VSOCK discussion and towards a
> > LSM stacking discussion; see my response to Gerd if you want to stay on
> > topic.]> 
> > On Saturday, February 23, 2013 03:43:23 PM Casey Schaufler wrote:
> >> On 2/22/2013 4:45 PM, Paul Moore wrote:
> >>> On Friday, February 22, 2013 03:00:04 PM Casey Schaufler wrote:
> >>>> Please add an LSM blob. Please do not use a secid. I am currently
> >>>> battling with secids in my efforts for multiple LSM support.
> >>>> 
> >>>> ...
> >>>> 
> >>>> I am going to be able to deal with secids for AF_INET only because
> >>>> SELinux prefers XFRM, Smack requires CIPSO, and AppArmor is going to
> >>>> be willing to have networking be optional.
> >>> 
> >>> "prefers"?  Really Casey, did you think I would let you get away with
> >>> that statement?  What a LSM "prefers" is really not relevant to the
> >>> stacking effort, what a LSM _supports_ is what matters.
> >> 
> >> I suppose. My point, which you may refute if it is incorrect,
> >> is that there are common, legitimate SELinux configurations which
> >> eschew Netlabel in favor of XFRM.
> > 
> > There are common, legitimate use cases which use exclusively NetLabel,
> > exclusively labeled IPsec, and both.  A LSM stacking design that forces
> > SELinux to only operate with XFRM (labeled IPsec) is wrong.  If you are
> > giving admins the ability to selectively stack LSMs you should also allow
> > them to selectively pick which non-shareable functionality they assign to
> > each LSM.
>
> That is the approach I'm taking. The kernel configuration
> will specify which LSM gets Netlabel and which gets XFRM.

Okay, it wasn't obvious to me in your previous emails that this was the case. 
Also, just so I'm clear, you configure the stacking and the stacked network 
access controls at the same time, yes?  I want to avoid the situation where 
the stacked network access controls are determined at build time and the LSM 
stacking order/configuration is determined at boot.
 
> >>> If you want to try option #3 I think we might be able to do something
> >>> with NetLabel to support multiple LSMs as the label abstraction stuff
> >>> should theoretically make this possible; although the NetLabel cache
> >>> will need some work.
> >> 
> >> It is reasonably easy to restrict Netlabel to a single LSM,
> >> and since SELinux seems better served by XFRM in most configurations ...
> > 
> > I disagree.  In some use cases SELinux is better served by XFRM, in others
> > it is better served by NetLabel.  Once again, I think you need to focus
> > on what is possible with the LSMs rather than a particular set of use
> > cases which happen to make the LSM stacking project easier.
> 
> I'm trying not to make too many architectural changes to the
> code around the LSM mechanism itself. I don't see that as cost
> effective or likely to be popular. If the implication of that is
> that there are certain configurations that are unsupportable but
> that have plausible alternatives I think it will do for phase I.

That statement is vague enough that I can't really say yes or no to it, but I 
will stick by my previous comments about the network access controls.

> >> Options I have considered include:
> >> 	- Netlabel support for discriminating LSM use by host,
> >> 	
> >> 	  just as it currently allows for unlabeled hosts.
> > 
> > Hmm, interesting ... not sure what I think of this.
> 
> It breaks down on 127.0.0.1. Otherwise is looks pretty easy to do.

When I said I wasn't sure what I thought of this, it was more along the lines 
of I'm not sure if it makes sense, not that it would be difficult to do.
 
> >> 	- secid maps.
> > 
> > Can you elaborate on this?  I can think of a few different meanings here
> > ...
>
> This fell out of my first shot at stacking, the one that never saw
> the light of day for tax reasons. I had implemented a stacker LSM
> that slid into the existing infrastructure. Hooks that asked for
> secids got the secid from my LSM, not the underlying LSM secids.
> There was a table much like the Smack label list that mapped the
> global secids to sets of underlying secids. The obvious problem
> is that that table grows quickly and can never go away.

Interesting idea, but I can imagine it gets rather intrusive very quickly.
 
-- 
paul moore
security and virtualization @ redhat


--
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: AF_VSOCK and the LSMs

[Casey Schaufler]

On 2/25/2013 1:05 PM, Paul Moore wrote:
> On Monday, February 25, 2013 10:02:42 AM Casey Schaufler wrote:
>> On 2/25/2013 8:55 AM, Paul Moore wrote:
>>> [NOTE/WARNING: we're veering away from the VSOCK discussion and towards a
>>> LSM stacking discussion; see my response to Gerd if you want to stay on
>>> topic.]> 
>>> On Saturday, February 23, 2013 03:43:23 PM Casey Schaufler wrote:
>>>> On 2/22/2013 4:45 PM, Paul Moore wrote:
>>>>> On Friday, February 22, 2013 03:00:04 PM Casey Schaufler wrote:
>>>>>> Please add an LSM blob. Please do not use a secid. I am currently
>>>>>> battling with secids in my efforts for multiple LSM support.
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> I am going to be able to deal with secids for AF_INET only because
>>>>>> SELinux prefers XFRM, Smack requires CIPSO, and AppArmor is going to
>>>>>> be willing to have networking be optional.
>>>>> "prefers"?  Really Casey, did you think I would let you get away with
>>>>> that statement?  What a LSM "prefers" is really not relevant to the
>>>>> stacking effort, what a LSM _supports_ is what matters.
>>>> I suppose. My point, which you may refute if it is incorrect,
>>>> is that there are common, legitimate SELinux configurations which
>>>> eschew Netlabel in favor of XFRM.
>>> There are common, legitimate use cases which use exclusively NetLabel,
>>> exclusively labeled IPsec, and both.  A LSM stacking design that forces
>>> SELinux to only operate with XFRM (labeled IPsec) is wrong.  If you are
>>> giving admins the ability to selectively stack LSMs you should also allow
>>> them to selectively pick which non-shareable functionality they assign to
>>> each LSM.
>> That is the approach I'm taking. The kernel configuration
>> will specify which LSM gets Netlabel and which gets XFRM.
> Okay, it wasn't obvious to me in your previous emails that this was the case. 
> Also, just so I'm clear, you configure the stacking and the stacked network 
> access controls at the same time, yes?  I want to avoid the situation where 
> the stacked network access controls are determined at build time and the LSM 
> stacking order/configuration is determined at boot.

The set of LSMs, the order they are invoked, which LSM
uses /proc/.../attr/current and which LSM uses Netlabel,
XFRM and secmark are all determined by Kconfig. You can
specify a limited set of LSMs using security= at boot,
but not the networking configuration.

Tetsuo is lobbying for loadable security modules. I am
doing my best to leave everything in a state where some
soul braver than I might pick that up after I'm done.
I do not have any intention of supporting on the fly
or heuristically determined networking.

 

>>>>> If you want to try option #3 I think we might be able to do something
>>>>> with NetLabel to support multiple LSMs as the label abstraction stuff
>>>>> should theoretically make this possible; although the NetLabel cache
>>>>> will need some work.
>>>> It is reasonably easy to restrict Netlabel to a single LSM,
>>>> and since SELinux seems better served by XFRM in most configurations ...
>>> I disagree.  In some use cases SELinux is better served by XFRM, in others
>>> it is better served by NetLabel.  Once again, I think you need to focus
>>> on what is possible with the LSMs rather than a particular set of use
>>> cases which happen to make the LSM stacking project easier.
>> I'm trying not to make too many architectural changes to the
>> code around the LSM mechanism itself. I don't see that as cost
>> effective or likely to be popular. If the implication of that is
>> that there are certain configurations that are unsupportable but
>> that have plausible alternatives I think it will do for phase I.
> That statement is vague enough that I can't really say yes or no to it, but I 
> will stick by my previous comments about the network access controls.

Ah. I want to create a useful system. I want to create it
reasonably short order. I am willing to forgo supporting
some configuration options to reduce the project time. In
particular, I hope to avoid mucking up other people's code
as that is a sure fire way to bog a project down.

>>>> Options I have considered include:
>>>> 	- Netlabel support for discriminating LSM use by host,
>>>> 	
>>>> 	  just as it currently allows for unlabeled hosts.
>>> Hmm, interesting ... not sure what I think of this.
>> It breaks down on 127.0.0.1. Otherwise is looks pretty easy to do.
> When I said I wasn't sure what I thought of this, it was more along the lines 
> of I'm not sure if it makes sense, not that it would be difficult to do.

It makes sense if you're in a network environment with heterogeneous
legacy multilevel secure systems and you want some of those machines
to talk to SELinux controlled processes and others to talk to Smack
controlled processes. That is unlikely to be an industry dominating
scenario.

>>>> 	- secid maps.
>>> Can you elaborate on this?  I can think of a few different meanings here
>>> ...
>> This fell out of my first shot at stacking, the one that never saw
>> the light of day for tax reasons. I had implemented a stacker LSM
>> that slid into the existing infrastructure. Hooks that asked for
>> secids got the secid from my LSM, not the underlying LSM secids.
>> There was a table much like the Smack label list that mapped the
>> global secids to sets of underlying secids. The obvious problem
>> is that that table grows quickly and can never go away.
> Interesting idea, but I can imagine it gets rather intrusive very quickly.

That's one way to describe it. I'm striving to avoid it.




--
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.

LSM stacking and the network access controls (was: AF_VSOCK and the LSMs)

[Paul Moore]

On Monday, February 25, 2013 03:06:14 PM Casey Schaufler wrote:
> On 2/25/2013 1:05 PM, Paul Moore wrote:
> > On Monday, February 25, 2013 10:02:42 AM Casey Schaufler wrote:
> >> On 2/25/2013 8:55 AM, Paul Moore wrote:
> >>> [NOTE/WARNING: we're veering away from the VSOCK discussion and towards
> >>> a LSM stacking discussion; see my response to Gerd if you want to stay
> >>> on topic.]
> >>> 
> >>> On Saturday, February 23, 2013 03:43:23 PM Casey Schaufler wrote:
> >>>> On 2/22/2013 4:45 PM, Paul Moore wrote:
> >>>>> On Friday, February 22, 2013 03:00:04 PM Casey Schaufler wrote:
> >>>>>> Please add an LSM blob. Please do not use a secid. I am currently
> >>>>>> battling with secids in my efforts for multiple LSM support.
> >>>>>> 
> >>>>>> ...
> >>>>>> 
> >>>>>> I am going to be able to deal with secids for AF_INET only because
> >>>>>> SELinux prefers XFRM, Smack requires CIPSO, and AppArmor is going to
> >>>>>> be willing to have networking be optional.
> >>>>> 
> >>>>> "prefers"?  Really Casey, did you think I would let you get away with
> >>>>> that statement?  What a LSM "prefers" is really not relevant to the
> >>>>> stacking effort, what a LSM _supports_ is what matters.
> >>>> 
> >>>> I suppose. My point, which you may refute if it is incorrect,
> >>>> is that there are common, legitimate SELinux configurations which
> >>>> eschew Netlabel in favor of XFRM.
> >>> 
> >>> There are common, legitimate use cases which use exclusively NetLabel,
> >>> exclusively labeled IPsec, and both.  A LSM stacking design that forces
> >>> SELinux to only operate with XFRM (labeled IPsec) is wrong.  If you are
> >>> giving admins the ability to selectively stack LSMs you should also
> >>> allow them to selectively pick which non-shareable functionality they
> >>> assign to each LSM.
> >> 
> >> That is the approach I'm taking. The kernel configuration
> >> will specify which LSM gets Netlabel and which gets XFRM.
> > 
> > Okay, it wasn't obvious to me in your previous emails that this was the
> > case. Also, just so I'm clear, you configure the stacking and the stacked
> > network access controls at the same time, yes?  I want to avoid the
> > situation where the stacked network access controls are determined at
> > build time and the LSM stacking order/configuration is determined at
> > boot.
> 
> The set of LSMs, the order they are invoked, which LSM
> uses /proc/.../attr/current and which LSM uses Netlabel,
> XFRM and secmark are all determined by Kconfig. You can
> specify a limited set of LSMs using security= at boot,
> but not the networking configuration.

That's unfortunate.  I'm _really_ not in favor of that, I would much rather 
see the non-shared LSM functionality assigned at the same time as the stacking 
order.  I'm not sure I'd NACK the current approach, or even if anyone would 
care that I did, but that is how I'm currently leaning with this split (build 
vs runtime) selection.
 
> Tetsuo is lobbying for loadable security modules. I am
> doing my best to leave everything in a state where some
> soul braver than I might pick that up after I'm done.
> I do not have any intention of supporting on the fly
> or heuristically determined networking.

Well, if that is the case I think the first-come-first-served approach to the 
non-shared functionality probably makes the most sense.  I understand why it 
might not be ideal in ever situation but it is predictable.

> >> I'm trying not to make too many architectural changes to the
> >> code around the LSM mechanism itself. I don't see that as cost
> >> effective or likely to be popular. If the implication of that is
> >> that there are certain configurations that are unsupportable but
> >> that have plausible alternatives I think it will do for phase I.
> > 
> > That statement is vague enough that I can't really say yes or no to it,
> > but I will stick by my previous comments about the network access
> > controls.
>
> Ah. I want to create a useful system. I want to create it
> reasonably short order. I am willing to forgo supporting
> some configuration options to reduce the project time. In
> particular, I hope to avoid mucking up other people's code
> as that is a sure fire way to bog a project down.

Usefulness is paramount of course and quickness is nice, but I do think it 
takes a back seat to "the right solution".  We're all going to have to live 
with this f-o-r-e-v-e-r, or at least what will surely seem like it, so I'd 
much rather we take the time to make sure we beat out as much ugly as we can 
before it is merged.
 
> >>>> Options I have considered include:
> >>>> 	- Netlabel support for discriminating LSM use by host,
> >>>> 	
> >>>> 	  just as it currently allows for unlabeled hosts.
> >>> 
> >>> Hmm, interesting ... not sure what I think of this.
> >> 
> >> It breaks down on 127.0.0.1. Otherwise is looks pretty easy to do.
> > 
> > When I said I wasn't sure what I thought of this, it was more along the
> > lines of I'm not sure if it makes sense, not that it would be difficult
> > to do.
>
> It makes sense if you're in a network environment with heterogeneous
> legacy multilevel secure systems and you want some of those machines
> to talk to SELinux controlled processes and others to talk to Smack
> controlled processes. That is unlikely to be an industry dominating
> scenario.

Well, you can talk MLS labeled networking to both SELinux and Smack, and you 
can talk MLS labeled networking between SELinux and Smack already (hip, hip, 
hooray for commonly accepted standards!) so I'm not sure you need this.  
Although I suppose it might simplify the configuration in some cases or help 
if you're trying to migrate from one LSM to another.

-- 
paul moore
security and virtualization @ redhat


--
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: LSM stacking and the network access controls

[Casey Schaufler]

On 2/26/2013 1:21 PM, Paul Moore wrote:
> On Monday, February 25, 2013 03:06:14 PM Casey Schaufler wrote:
>> On 2/25/2013 1:05 PM, Paul Moore wrote:
>>> On Monday, February 25, 2013 10:02:42 AM Casey Schaufler wrote:
>>>> On 2/25/2013 8:55 AM, Paul Moore wrote:
>>>>> [NOTE/WARNING: we're veering away from the VSOCK discussion and towards
>>>>> a LSM stacking discussion; see my response to Gerd if you want to stay
>>>>> on topic.]
>>>>>
>>>>> On Saturday, February 23, 2013 03:43:23 PM Casey Schaufler wrote:
>>>>>> On 2/22/2013 4:45 PM, Paul Moore wrote:
>>>>>>> On Friday, February 22, 2013 03:00:04 PM Casey Schaufler wrote:
>>>>>>>> Please add an LSM blob. Please do not use a secid. I am currently
>>>>>>>> battling with secids in my efforts for multiple LSM support.
>>>>>>>>
>>>>>>>> ...
>>>>>>>>
>>>>>>>> I am going to be able to deal with secids for AF_INET only because
>>>>>>>> SELinux prefers XFRM, Smack requires CIPSO, and AppArmor is going to
>>>>>>>> be willing to have networking be optional.
>>>>>>> "prefers"?  Really Casey, did you think I would let you get away with
>>>>>>> that statement?  What a LSM "prefers" is really not relevant to the
>>>>>>> stacking effort, what a LSM _supports_ is what matters.
>>>>>> I suppose. My point, which you may refute if it is incorrect,
>>>>>> is that there are common, legitimate SELinux configurations which
>>>>>> eschew Netlabel in favor of XFRM.
>>>>> There are common, legitimate use cases which use exclusively NetLabel,
>>>>> exclusively labeled IPsec, and both.  A LSM stacking design that forces
>>>>> SELinux to only operate with XFRM (labeled IPsec) is wrong.  If you are
>>>>> giving admins the ability to selectively stack LSMs you should also
>>>>> allow them to selectively pick which non-shareable functionality they
>>>>> assign to each LSM.
>>>> That is the approach I'm taking. The kernel configuration
>>>> will specify which LSM gets Netlabel and which gets XFRM.
>>> Okay, it wasn't obvious to me in your previous emails that this was the
>>> case. Also, just so I'm clear, you configure the stacking and the stacked
>>> network access controls at the same time, yes?  I want to avoid the
>>> situation where the stacked network access controls are determined at
>>> build time and the LSM stacking order/configuration is determined at
>>> boot.
>> The set of LSMs, the order they are invoked, which LSM
>> uses /proc/.../attr/current and which LSM uses Netlabel,
>> XFRM and secmark are all determined by Kconfig. You can
>> specify a limited set of LSMs using security= at boot,
>> but not the networking configuration.
> That's unfortunate.  I'm _really_ not in favor of that, I would much rather 
> see the non-shared LSM functionality assigned at the same time as the stacking 
> order.  I'm not sure I'd NACK the current approach, or even if anyone would 
> care that I did, but that is how I'm currently leaning with this split (build 
> vs runtime) selection.

I'm not against that approach. How would you see it working?

The distro compiles in all the LSMs.
They specify that SELinux gets xfrm and secmark.
They specify the Smack gets Netlabel.
They tell (the new and improved) AppArmor to eschew networking.
They specify a boot order of "selinux,smack,apparmor,yama"
(They left off tomoyo for tax purposes).

On the boot line, the user types "security=apparmor".

What should happen?

>  
>> Tetsuo is lobbying for loadable security modules. I am
>> doing my best to leave everything in a state where some
>> soul braver than I might pick that up after I'm done.
>> I do not have any intention of supporting on the fly
>> or heuristically determined networking.
> Well, if that is the case I think the first-come-first-served approach to the 
> non-shared functionality probably makes the most sense.  I understand why it 
> might not be ideal in ever situation but it is predictable.

Would you have the same opinion if SELinux were last,
instead of first? SELinux is the most feature rich of
the LSMs and no other LSM would ever get networking in
the presence of SELinux.


>>>> I'm trying not to make too many architectural changes to the
>>>> code around the LSM mechanism itself. I don't see that as cost
>>>> effective or likely to be popular. If the implication of that is
>>>> that there are certain configurations that are unsupportable but
>>>> that have plausible alternatives I think it will do for phase I.
>>> That statement is vague enough that I can't really say yes or no to it,
>>> but I will stick by my previous comments about the network access
>>> controls.
>> Ah. I want to create a useful system. I want to create it
>> reasonably short order. I am willing to forgo supporting
>> some configuration options to reduce the project time. In
>> particular, I hope to avoid mucking up other people's code
>> as that is a sure fire way to bog a project down.
> Usefulness is paramount of course

Agreed

> and quickness is nice,

If it drags on too long the boss gets cranky. And "labelled" NFSv4.2
gets done. And the list macros get reworked. And ....

> but I do think it takes a back seat to "the right solution".

If I had two years and didn't have to worry about anyone else's
changes and weren't beholden to retaining some of the past's more
interesting design choices I'd be more concerned about "right" than
"good".

> We're all going to have to live with this f-o-r-e-v-e-r,

Assuming it gets adopted. It will have to be good enough for that.
There is no guarantee on that.

> or at least what will surely seem like it, so I'd 
> much rather we take the time to make sure we beat out as much ugly as we can 
> before it is merged.

I'm with you there. I just hope the ugly hasn't been lifting weights.

 

>>>>>> Options I have considered include:
>>>>>> 	- Netlabel support for discriminating LSM use by host,
>>>>>> 	
>>>>>> 	  just as it currently allows for unlabeled hosts.
>>>>> Hmm, interesting ... not sure what I think of this.
>>>> It breaks down on 127.0.0.1. Otherwise is looks pretty easy to do.
>>> When I said I wasn't sure what I thought of this, it was more along the
>>> lines of I'm not sure if it makes sense, not that it would be difficult
>>> to do.
>> It makes sense if you're in a network environment with heterogeneous
>> legacy multilevel secure systems and you want some of those machines
>> to talk to SELinux controlled processes and others to talk to Smack
>> controlled processes. That is unlikely to be an industry dominating
>> scenario.
> Well, you can talk MLS labeled networking to both SELinux and Smack, and you 
> can talk MLS labeled networking between SELinux and Smack already (hip, hip, 
> hooray for commonly accepted standards!)

And Paul gets a pat on the back! The crowd goes wild!

> so I'm not sure you need this.  
> Although I suppose it might simplify the configuration in some cases or help 
> if you're trying to migrate from one LSM to another.

It's a nutty scenario. It would allow Smack and SELinux to divide the
hosts amongst them, and if SELinux wasn't going to use Netlabel for
on the box (127.0.0.1) communications anyway, Smack could use that
and be very happy.


--
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: LSM stacking and the network access controls

[Paul Moore]

On Tuesday, February 26, 2013 03:12:31 PM Casey Schaufler wrote:
> On 2/26/2013 1:21 PM, Paul Moore wrote:
> > On Monday, February 25, 2013 03:06:14 PM Casey Schaufler wrote:
> >> The set of LSMs, the order they are invoked, which LSM
> >> uses /proc/.../attr/current and which LSM uses Netlabel,
> >> XFRM and secmark are all determined by Kconfig. You can
> >> specify a limited set of LSMs using security= at boot,
> >> but not the networking configuration.
> > 
> > That's unfortunate.  I'm _really_ not in favor of that, I would much
> > rather see the non-shared LSM functionality assigned at the same time as
> > the stacking order.  I'm not sure I'd NACK the current approach, or even\
> > if anyone would care that I did, but that is how I'm currently leaning
> > with this split (build vs runtime) selection.
> 
> I'm not against that approach. How would you see it working?
> 
> The distro compiles in all the LSMs.
> They specify that SELinux gets xfrm and secmark.
> They specify the Smack gets Netlabel.
> They tell (the new and improved) AppArmor to eschew networking.
> They specify a boot order of "selinux,smack,apparmor,yama"
> (They left off tomoyo for tax purposes).
> 
> On the boot line, the user types "security=apparmor".
> 
> What should happen?

Okay, I misunderstood what was specified at boot time; I thought the stacking 
order could be defined at boot but based on your example I'm guessing the 
stacking order is defined at compile time and you can only enable/disable LSMs 
at boot?

> >> Tetsuo is lobbying for loadable security modules. I am
> >> doing my best to leave everything in a state where some
> >> soul braver than I might pick that up after I'm done.
> >> I do not have any intention of supporting on the fly
> >> or heuristically determined networking.
> > 
> > Well, if that is the case I think the first-come-first-served approach to
> > the non-shared functionality probably makes the most sense.  I understand
> > why it might not be ideal in ever situation but it is predictable.
> 
> Would you have the same opinion if SELinux were last, instead of first?

Yes.

In fact, considering the example above, and also assuming I'm understanding it 
correctly, I think I am more in favor of the first-come-first-served approach 
since you can enable/disable LSMs at boot.  Imagine if you gave one LSM all 
the non-shared functionality but disabled it at boot in favor of another LSM 
which could make use of some of this functionality but was denied due to the 
compile time option.  This seems much more useful to me.

> >>>> I'm trying not to make too many architectural changes to the
> >>>> code around the LSM mechanism itself. I don't see that as cost
> >>>> effective or likely to be popular. If the implication of that is
> >>>> that there are certain configurations that are unsupportable but
> >>>> that have plausible alternatives I think it will do for phase I.
> >>> 
> >>> That statement is vague enough that I can't really say yes or no to it,
> >>> but I will stick by my previous comments about the network access
> >>> controls.
> >> 
> >> Ah. I want to create a useful system. I want to create it
> >> reasonably short order. I am willing to forgo supporting
> >> some configuration options to reduce the project time. In
> >> particular, I hope to avoid mucking up other people's code
> >> as that is a sure fire way to bog a project down.
> > 
> > Usefulness is paramount of course
> 
> Agreed
> 
> > and quickness is nice,
> 
> If it drags on too long the boss gets cranky. And "labelled" NFSv4.2
> gets done. And the list macros get reworked. And ....
> 
> > but I do think it takes a back seat to "the right solution".
> 
> If I had two years and didn't have to worry about anyone else's
> changes and weren't beholden to retaining some of the past's more
> interesting design choices I'd be more concerned about "right" than
> "good".
> 
> > We're all going to have to live with this f-o-r-e-v-e-r,
> 
> Assuming it gets adopted. It will have to be good enough for that.
> There is no guarantee on that.
> 
> > or at least what will surely seem like it, so I'd much rather we take the
> > time to make sure we beat out as much ugly as we can before it is merged.
> 
> I'm with you there. I just hope the ugly hasn't been lifting weights.

February is "fitness month".

-- 
paul moore
security and virtualization @ redhat


--
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: LSM stacking and the network access controls

[Casey Schaufler]

On 2/27/2013 8:43 AM, Paul Moore wrote:
> On Tuesday, February 26, 2013 03:12:31 PM Casey Schaufler wrote:
>> On 2/26/2013 1:21 PM, Paul Moore wrote:
>>> On Monday, February 25, 2013 03:06:14 PM Casey Schaufler wrote:
>>>> The set of LSMs, the order they are invoked, which LSM
>>>> uses /proc/.../attr/current and which LSM uses Netlabel,
>>>> XFRM and secmark are all determined by Kconfig. You can
>>>> specify a limited set of LSMs using security= at boot,
>>>> but not the networking configuration.
>>> That's unfortunate.  I'm _really_ not in favor of that, I would much
>>> rather see the non-shared LSM functionality assigned at the same time as
>>> the stacking order.  I'm not sure I'd NACK the current approach, or even\
>>> if anyone would care that I did, but that is how I'm currently leaning
>>> with this split (build vs runtime) selection.
>> I'm not against that approach. How would you see it working?
>>
>> The distro compiles in all the LSMs.
>> They specify that SELinux gets xfrm and secmark.
>> They specify the Smack gets Netlabel.
>> They tell (the new and improved) AppArmor to eschew networking.
>> They specify a boot order of "selinux,smack,apparmor,yama"
>> (They left off tomoyo for tax purposes).
>>
>> On the boot line, the user types "security=apparmor".
>>
>> What should happen?
> Okay, I misunderstood what was specified at boot time; I thought the stacking 
> order could be defined at boot but based on your example I'm guessing the 
> stacking order is defined at compile time and you can only enable/disable LSMs 
> at boot?

Well, no. It looks as if I gave a poor example.

	"security=apparmor,tomoyo,selinux"

is legitimate and indicates that AppArmor goes first,
then TOMOYO, then SELinux. No LSM gets NetLabel because
that was allocated to Smack. SELinux gets XFRM and secmark.
 

>>>> Tetsuo is lobbying for loadable security modules. I am
>>>> doing my best to leave everything in a state where some
>>>> soul braver than I might pick that up after I'm done.
>>>> I do not have any intention of supporting on the fly
>>>> or heuristically determined networking.
>>> Well, if that is the case I think the first-come-first-served approach to
>>> the non-shared functionality probably makes the most sense.  I understand
>>> why it might not be ideal in ever situation but it is predictable.
>> Would you have the same opinion if SELinux were last, instead of first?
> Yes.
>
> In fact, considering the example above, and also assuming I'm understanding it 
> correctly, I think I am more in favor of the first-come-first-served approach 
> since you can enable/disable LSMs at boot.  Imagine if you gave one LSM all 
> the non-shared functionality but disabled it at boot in favor of another LSM 
> which could make use of some of this functionality but was denied due to the 
> compile time option.  This seems much more useful to me.
>
>>>>>> I'm trying not to make too many architectural changes to the
>>>>>> code around the LSM mechanism itself. I don't see that as cost
>>>>>> effective or likely to be popular. If the implication of that is
>>>>>> that there are certain configurations that are unsupportable but
>>>>>> that have plausible alternatives I think it will do for phase I.
>>>>> That statement is vague enough that I can't really say yes or no to it,
>>>>> but I will stick by my previous comments about the network access
>>>>> controls.
>>>> Ah. I want to create a useful system. I want to create it
>>>> reasonably short order. I am willing to forgo supporting
>>>> some configuration options to reduce the project time. In
>>>> particular, I hope to avoid mucking up other people's code
>>>> as that is a sure fire way to bog a project down.
>>> Usefulness is paramount of course
>> Agreed
>>
>>> and quickness is nice,
>> If it drags on too long the boss gets cranky. And "labelled" NFSv4.2
>> gets done. And the list macros get reworked. And ....
>>
>>> but I do think it takes a back seat to "the right solution".
>> If I had two years and didn't have to worry about anyone else's
>> changes and weren't beholden to retaining some of the past's more
>> interesting design choices I'd be more concerned about "right" than
>> "good".
>>
>>> We're all going to have to live with this f-o-r-e-v-e-r,
>> Assuming it gets adopted. It will have to be good enough for that.
>> There is no guarantee on that.
>>
>>> or at least what will surely seem like it, so I'd much rather we take the
>>> time to make sure we beat out as much ugly as we can before it is merged.
>> I'm with you there. I just hope the ugly hasn't been lifting weights.
> February is "fitness month".



--
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: LSM stacking and the network access controls

[Paul Moore]

On Wednesday, February 27, 2013 08:51:50 AM Casey Schaufler wrote:
> On 2/27/2013 8:43 AM, Paul Moore wrote:
> > On Tuesday, February 26, 2013 03:12:31 PM Casey Schaufler wrote:
> >> On 2/26/2013 1:21 PM, Paul Moore wrote:
> >>> On Monday, February 25, 2013 03:06:14 PM Casey Schaufler wrote:
> >>>> The set of LSMs, the order they are invoked, which LSM
> >>>> uses /proc/.../attr/current and which LSM uses Netlabel,
> >>>> XFRM and secmark are all determined by Kconfig. You can
> >>>> specify a limited set of LSMs using security= at boot,
> >>>> but not the networking configuration.
> >>> 
> >>> That's unfortunate.  I'm _really_ not in favor of that, I would much
> >>> rather see the non-shared LSM functionality assigned at the same time as
> >>> the stacking order.  I'm not sure I'd NACK the current approach, or
> >>> even\
> >>> if anyone would care that I did, but that is how I'm currently leaning
> >>> with this split (build vs runtime) selection.
> >> 
> >> I'm not against that approach. How would you see it working?
> >> 
> >> The distro compiles in all the LSMs.
> >> They specify that SELinux gets xfrm and secmark.
> >> They specify the Smack gets Netlabel.
> >> They tell (the new and improved) AppArmor to eschew networking.
> >> They specify a boot order of "selinux,smack,apparmor,yama"
> >> (They left off tomoyo for tax purposes).
> >> 
> >> On the boot line, the user types "security=apparmor".
> >> 
> >> What should happen?
> > 
> > Okay, I misunderstood what was specified at boot time; I thought the
> > stacking order could be defined at boot but based on your example I'm
> > guessing the stacking order is defined at compile time and you can only
> > enable/disable LSMs at boot?
> 
> Well, no. It looks as if I gave a poor example.
> 
> 	"security=apparmor,tomoyo,selinux"
> 
> is legitimate and indicates that AppArmor goes first,
> then TOMOYO, then SELinux. No LSM gets NetLabel because
> that was allocated to Smack. SELinux gets XFRM and secmark.

All the more reason to either adopt a mechanism that allows you to assign the 
non-shareable resources on the command line along with the stacking 
configuration or simply adopt a first-come-first-serve policy.

-- 
paul moore
security and virtualization @ redhat


--
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: LSM stacking and the network access controls

[Casey Schaufler]

On 2/27/2013 9:31 AM, Paul Moore wrote:
> On Wednesday, February 27, 2013 08:51:50 AM Casey Schaufler wrote:
>> On 2/27/2013 8:43 AM, Paul Moore wrote:
>>> On Tuesday, February 26, 2013 03:12:31 PM Casey Schaufler wrote:
>>>> On 2/26/2013 1:21 PM, Paul Moore wrote:
>>>>> On Monday, February 25, 2013 03:06:14 PM Casey Schaufler wrote:
>>>>>> The set of LSMs, the order they are invoked, which LSM
>>>>>> uses /proc/.../attr/current and which LSM uses Netlabel,
>>>>>> XFRM and secmark are all determined by Kconfig. You can
>>>>>> specify a limited set of LSMs using security= at boot,
>>>>>> but not the networking configuration.
>>>>> That's unfortunate.  I'm _really_ not in favor of that, I would much
>>>>> rather see the non-shared LSM functionality assigned at the same time as
>>>>> the stacking order.  I'm not sure I'd NACK the current approach, or
>>>>> even\
>>>>> if anyone would care that I did, but that is how I'm currently leaning
>>>>> with this split (build vs runtime) selection.
>>>> I'm not against that approach. How would you see it working?
>>>>
>>>> The distro compiles in all the LSMs.
>>>> They specify that SELinux gets xfrm and secmark.
>>>> They specify the Smack gets Netlabel.
>>>> They tell (the new and improved) AppArmor to eschew networking.
>>>> They specify a boot order of "selinux,smack,apparmor,yama"
>>>> (They left off tomoyo for tax purposes).
>>>>
>>>> On the boot line, the user types "security=apparmor".
>>>>
>>>> What should happen?
>>> Okay, I misunderstood what was specified at boot time; I thought the
>>> stacking order could be defined at boot but based on your example I'm
>>> guessing the stacking order is defined at compile time and you can only
>>> enable/disable LSMs at boot?
>> Well, no. It looks as if I gave a poor example.
>>
>> 	"security=apparmor,tomoyo,selinux"
>>
>> is legitimate and indicates that AppArmor goes first,
>> then TOMOYO, then SELinux. No LSM gets NetLabel because
>> that was allocated to Smack. SELinux gets XFRM and secmark.
> All the more reason to either adopt a mechanism that allows you to assign the 
> non-shareable resources on the command line along with the stacking 
> configuration or simply adopt a first-come-first-serve policy.

I will think on this. I'm not sure I'll be happy however it ends up.


--
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.