Re: selinux vs devtmpfs (vs udev)

From: Harald Hoyer
Date: Tue Aug 31 2010 - 10:39:28 EST


On 08/31/2010 04:11 PM, Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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?

-Eric


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().

So the problem is happening because the kernel creates the device rather
then udev, and then udev does not change the context because it can not
differentiate between this and libvirt putting down a label.

Is there an easy test to differentiate?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/