Re: selinux vs devtmpfs (vs udev)

[Daniel J Walsh <dwalsh@redhat.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/31/2010 11:16 AM, Eric Paris wrote:
> On Tue, 2010-08-31 at 10:57 -0400, Daniel J Walsh wrote:
>> On 08/31/2010 10:39 AM, Harald Hoyer wrote:
>>> On 08/31/2010 04:11 PM, Daniel J Walsh wrote:
>>>> On 08/31/2010 04:44 AM, Harald Hoyer wrote:
>>>>> On 08/31/2010 01:14 AM, Eric Paris wrote:
>>>>>> On Sat, 2010-08-28 at 11:57 +0200, Kay Sievers wrote:
>>>>>>> On Sat, Aug 28, 2010 at 01:00, Eric Paris<eparis@redhat.com>   wrote:
>>>>>>
>>>>>>>> In the new new days of devtmpfs things aren't as nice.  The kernel is
>>>>>>>> magically creating files in /dev.  These are getting created with the
>>>>>>>> 'default' SELinux context.  So herein lies the problem.
>>>>>>>>
>>>>>>>> The first program that tries to access these files get denied by
>>>>>>>> SELinux.  Now udev actually has logic in it to fix the label on any
>>>>>>>> closed device file, so udev will at that point swoop in, fix the
>>>>>>>> label,
>>>>>>>> and the next program that tries to use the file will work just
>>>>>>>> fine.  Oh
>>>>>>>> fun!
>>>>>>
>>>>>>> Udev should still label all device nodes, even when they are created
>>>>>>> by the kernel. Devtmpfs or not should not make a difference here.
>>>>>>>
>>>>>>> I guess it's a udev bug introduced with:
>>>>>>>
>>>>>>> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=578cc8a8085a47c963b5940459e475ac5f07219c
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> and we just need to fix that.
>>>>>>
>>>>>> Looks like the likely cause.  I see a note in one of the bugzillas that
>>>>>> says:
>>>>>>
>>>>>> Aug 30 14:03:09 pippin udevd-work[347]: preserve file '/dev/dri/card0',
>>>>>> because it has correct dev_t
>>>>>>
>>>>>> Which is certainly the part of code in question.  Do you have a quick
>>>>>> fix in mind that you plan to push upstream or should I ask the RH udev
>>>>>> guy to come up with something?
> 
>>>>> The RH udev guy says:
>>>>>
>>>>> This patch was introduced, because Red Hat engineers requested, that the
>>>>> selinux context should not be modified, after they set their own custom
>>>>> context (virtual machine management).
>>>>>
>>>>> So, either we differentiate between "add" and "change" events, or we
>>>>> should check against the "kernel default" selinux context, before we
>>>>> call udev_selinux_lsetfilecon().
> 
> How does udev get notification of add and change events?  add vs change
> seems like the best medium term solution.
> 
> Short term checking for the 'default' and resetting if it is default
> seems like a reasonable solution. But of course determining that default
> is not as easy as you might like.
> 
> Dan has suggested 2 heuristics.
> 
> 1) do not change if the MLS component is not ":s0"
>    - this is a terrible hack.  don't do it.
> 2) only change if the label is the same as the parent
>    - this is a lot better, but I'd still a heuristic of the next one
> 
> I suggest a third options: Calculate the default at startup and on every
> policy load and fix object labels if they are the default.  I'm sure Dan
> knows a code example of how to do the calculation.  The pseudocode looks
> something like:


> 
> lookup the label on /dev
> lookup the label on the initial task
> ask the kernel what the resulting label on a file transition with those
> two pieces of information will be.


NOOOOO

libvirt is going in and changing fixed_disk_device_t:s0 to svirt_t:c0,c124

We do not want udev to see this and ask what label a device should have
if libvirtd_t created a chr_file in device_t.

> 
> It's sad to write all this code when I know the answer 99.9999999999% of
> the time already, but if we are going to do it right.......
> 
> -Eric
> 
I think either figure out if the device is newly created versus modified
or check the parent directory.
> 
> --
> 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.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkx9HhsACgkQrlYvE4MpobM1yQCeLyZiOUGQMG25Y/DYwzAsrxmp
OzMAoKGe6d3LV3PZFVXbHul1A+mKc6lE
=GZ7i
-----END PGP SIGNATURE-----