Re: The problem with TUN/TAP devices

[Casey Schaufler <casey@schaufler-ca.com>]

Paul Moore wrote:
> Unfortunately we have a problem with the network access controls and TUN/TAP 
> devices.  The basic issue is that packets entering the stack via a TUN device, 
> e.g. QEMU/KVM guest instance operating with a bridged network configuration, 
> do not have a fully initialized sock associated with them.  I say "fully 
> initialized" because the basic initialization has been done (memory allocated, 
> initial values set to SECINITSID_UNLABELED, etc.) but the last step where we 
> assign the sock a label/SID never happens.  Why?  Because the TUN driver code 
> only calls sk_alloc() and nothing else in the TUN code paths finish the 
> SELinux sock setup.
>   

So what should it be calling and why is the fact that it isn't not a bug
in the TUN driver?

> Okay, so what?  Well, the problem is that the SELinux IP postrouting code 
> treats the packet's sock label (the one that is still set as unlabeled_t in 
> the TUN case) as the originating peer label; in short it looks like packets 
> sent from your QEMU/KVM instance are unlabeled_t instead of my_guest_t:s3.  
> Needless to say this is not ideal.
>
> So how do we fix it?  Well, there are a two options that I can think of right 
> now (feel free to add to the list):
>
> 1. Set the sock's label/SID in sk_alloc()
> 2. Introduce a new hook to set the label/SID of a sock and call it from
>    tun_set_iff()
>
> The problem with #2 is that it introduces a new (basically TUN specific) hook 
> to do something silly.  Important, but still kinda silly.  The problem with #1 
> is that we currently set the sock's label/SID in selinux_socket_post_create() 
> and match it with the inode's label/SID which has the potential to get ugly (I 
> haven't verified all of those cases yet).  However, there may be an 
> alternative, call it #1a, where set label the sock in sk_alloc() and then use 
> the sock's label to set the inode's label in socket_post_create(); this should 
> solve the potential ugliness.
>
> Thoughts?
>
>   

As this would appear to be a flaw in the TUN driver, get the TUN
developers to fix their broken driver. I certainly dislike a special
purpose LSM hook for this.

Do you see this as a problem for all users of labeled networking,
or is it isolated to SELinux?

> There is also a somewhat related issue involving persistent TUN/TAP devices 
> but I'd like to resolve this before getting deeper into that problem.
>
>   

Oh joy.

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