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@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
