Message-ID: <5127F874.1050907@schaufler-ca.com>
Date:	Fri, 22 Feb 2013 15:00:04 -0800
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	Paul Moore <pmoore@...hat.com>
CC:	netdev@...r.kernel.org, linux-security-module@...r.kernel.org,
	selinux@...ho.nsa.gov, Andy King <acking@...are.com>,
	Gerd Hoffmann <kraxel@...hat.com>,
	Eric Paris <eparis@...hat.com>,
	Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: AF_VSOCK and the LSMs

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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists