-----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@xxxxxxxxxx> 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@xxxxxxxxxxxxx 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----- -- 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.
