Re: The problem with TUN/TAP devices
Casey Schaufler <casey@...
2009-07-01 03:32:30 GMT
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
> 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