[libvirt] [PATCH v2 2/2] selinux: add security selinux function to label tapfd

[Guannan Ren]

On 10/17/2012 03:19 AM, Eric Blake wrote:
> On 10/15/2012 03:03 AM, Guannan Ren wrote:
>> BZ:https://bugzilla.redhat.com/show_bug.cgi?id=851981
>> When using macvtap, a character device gets first created by
>> kernel with name /dev/tapN, its selinux context is:
>> system_u:object_r:device_t:s0
>>
>> Shortly, when udev gets notification when new file is created
>> in /dev, it will then jump in and relabel this file back to the
>> expected default context:
>> system_u:object_r:tun_tap_device_t:s0
>>
>> There is a time gap happened.
>> Sometimes, it will have migration failed, AVC error message:
>> type=AVC msg=audit(1349858424.233:42507): avc:  denied  { read write } for
>> pid=19926 comm="qemu-kvm" path="/dev/tap33" dev=devtmpfs ino=131524
>> scontext=unconfined_u:system_r:svirt_t:s0:c598,c908
>> tcontext=system_u:object_r:device_t:s0 tclass=chr_file
>>
>> This patch will label the tapfd device before qemu process starts:
>> system_u:object_r:tun_tap_device_t:MCS(MCS from seclabel->label)
>> ---
> This patch is breaking things for me - with it applied, I'm now seeing
> /dev/net/tun with a label of :MCS that matches the most recently started
> guest, which prevents other tun clients (like openvpn) from creating
> their own tapfd.  I haven't yet looked closely to see where in this
> patch you are labeling the wrong file, but it needs to be fixed.
>

     Sorry, that is a really stupid mistake I made.
     I should relabel  tapfd of virtual network of type 
VIR_DOMAIN_NET_TYPE_DIRECT
     rather than VIR_DOMAIN_NET_TYPE_NETWORK and VIR_DOMAIN_NET_TYPE_BRIDGE.
     Patch has sent out.

     Guannan