[libvirt] [PATCH] security_selinux: Don't relabel /dev/net/tun

[Michal Privoznik]

On 07.10.2014 17:19, Eric Blake wrote:
> On 10/07/2014 08:53 AM, Michal Privoznik wrote:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1147057
>>
>> The code for relabelling the TAP FD is there due to a race. When
>> libvirt creates a /dev/tapN device it's labeled as
>> 'system_u:object_r:device_t:s0' by default. Later, when
>> udev/systemd reacts to this device, it's relabelled to the
>> expected label 'system_u:object_r:tun_tap_device_t:s0'. Hence, we
>> have a code that relabels the device, to cut the race down. For
>> more info see ae368ebfcc4.
>>
>> But the problem is, the relabel function is called on all TUN/TAP
>> devices. Yes, on /dev/net/tun too. This is however a special kind
>> of device - other processes uses it too. We shouldn't touch it's
>> label then.
>>
>> Ideally, there would an API in SELinux that would label just the
>> passed FD and not the underlying path. That way, we wouldn't need
>> to care as we would be not labeling /dev/net/tun but the FD
>> passed to the domain. Unfortunately, there's no such API so we
>> have to workaround until then.
>>
>
>> +
>> +    if (!STRPREFIX(fd_path, "/dev/tap")) {
>
> Should this be "/dev/tap.", since...
>
>> +        VIR_DEBUG("fd=%d points to %s not setting SELinux label",
>> +                  fd, fd_path);
>> +        rc = 0;
>> +        goto cleanup;
>> +    }
>> +
>>       if (getContext(mgr, "/dev/tap.*", buf.st_mode, &fcon) < 0) {
>
> ...you require a '.' in the context lookup?  Without the '.' in the
> filter, you would let the (unlikely) name '/dev/tapX' get through.
>
> ACK with that tweaked.
>
>

In fact, /dev/tapX is what is created. getContext should be using it too 
as it accepts shell expendable names, not regular expressions. I'm 
adjusting getContext's argument too.

Michal