selinux vs devtmpfs (vs udev)
Eric Paris
https://bugzilla.redhat.com/show_bug.cgi?id=566332
https://bugzilla.redhat.com/show_bug.cgi?id=627710
Where (I'm assuming) devtmpfs and SELinux are fighting. In the old old
days we used to have a script that would, after having created
everything in /dev, set the proper SELinux labels on those files. This
was done so early in boot that races didn't exist yet.
In the new days udev would create nodes in there, but udev is SELinux
aware. udev will determine what the right SELinux context is, will tell
the kernel what the next file it creates should be labeled, and will
then call mknod, so the device file gets created with the right label.
Again race free.
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!
Obviously a good solution would be for devtmpfs to create nodes with the
right label (and udev to not need to be SELinux aware), but that
information isn't available in the kernel. That information is a purely
userspace construct. I have a long term plan for how we might be able
to do this long off in the future, but it isn't viable for right now.
So my next best solution would be to ask if it would be possible for
udev to disable devtmpfs automatic device file creation after it is
running. Once udev is running do we need devtmpfs? Seems like this
could be a pretty simple /proc/ or /sys/ tunable that udev could twiddle
when/if it was ready to run the show.
Anyone else have thoughts?
-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Eric Paris
> On Sat, Aug 28, 2010 at 01:00, Eric Paris <epa...@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?
Harald Hoyer
> On Sat, 2010-08-28 at 11:57 +0200, Kay Sievers wrote:
>> On Sat, Aug 28, 2010 at 01:00, Eric Paris<epa...@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?
>
> -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().
Daniel J Walsh
Hash: SHA1
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkx9Da0ACgkQrlYvE4MpobOYKwCeK1IcX1z/B1lqMbkhYRTVNGsc
o3gAn02Q+xVyfmRysEqvLT36ea3EUeHZ
=3H/v
-----END PGP SIGNATURE-----
Harald Hoyer
Is there an easy test to differentiate?
Daniel J Walsh
Hash: SHA1
Why is the kernel creating the devices versus telling udev to create the
devices?
You could write a hack that says don't relabel devices with MLS != s0.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkx9GDYACgkQrlYvE4MpobMBBACfen8P0i1LJjufe2Gzdi2mn+tM
OdwAn1nHM1M34MGahwS7tNlLLpfmadcC
=hBOX
-----END PGP SIGNATURE-----
Daniel J Walsh
Hash: SHA1
Another option would be to check the label of the containing directory
and if they match run the lsetfilecon, If they don't then leave it be.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkx9GGgACgkQrlYvE4MpobNwkgCgvzHFWYTZND+xMSukZXc1M+a0
fC4AoNaVap4UfoOoq1U+8X7JWYqktNHy
=TljD
-----END PGP SIGNATURE-----
Eric Paris
> >>> 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.
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
Daniel J Walsh
Hash: SHA1
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 majo...@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-----
Eric Paris
> On 08/31/2010 11:16 AM, Eric Paris wrote:
> > 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.
initial task == /sbin/init
actually I should look if the kernel init_cred (what devtmpfs uses to
make security decisions) is initrc_t or kernel_t. I'm guessing it is
kernel_t but I'm not certain how that gets set.....
-Eric
Harald Hoyer
> On Tue, 2010-08-31 at 11:22 -0400, Daniel J Walsh wrote:
>> On 08/31/2010 11:16 AM, Eric Paris wrote:
>
>>> 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.
>
> initial task == /sbin/init
>
> actually I should look if the kernel init_cred (what devtmpfs uses to
> make security decisions) is initrc_t or kernel_t. I'm guessing it is
> kernel_t but I'm not certain how that gets set.....
>
> -Eric
>
https://bugzilla.redhat.com/show_bug.cgi?id=575128#c14
https://bugzilla.redhat.com/attachment.cgi?id=442223&format=raw
udev/udev-node.c
+ /* set selinux file context on add events */
+ if (strcmp(udev_device_get_action(dev), "add") == 0)
+ udev_selinux_lsetfilecon(udev, file, mode);
Daniel J Walsh
Hash: SHA1
On 08/31/2010 03:32 PM, Kay Sievers wrote:
> On Tue, Aug 31, 2010 at 17:49, Harald Hoyer <har...@redhat.com> wrote:
>> https://bugzilla.redhat.com/show_bug.cgi?id=575128#c14
>> https://bugzilla.redhat.com/attachment.cgi?id=442223&format=raw
>>
>> udev/udev-node.c
>>
>> + /* set selinux file context on add events */
>> + if (strcmp(udev_device_get_action(dev), "add") == 0)
>> + udev_selinux_lsetfilecon(udev, file, mode);
>
> I can't access these bugs.
>
> Does that makes sense/work for you?
> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=326c5fc3ea684825629eccaf33a548759162a539
>
> Kay
If it only labels on node creation, yes that makes sense to me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkx9WgAACgkQrlYvE4MpobPoJgCeLTV4TWUi0Mh/m0P783/PPyBa
s2MAnRK5pUSJqVT+mAHtxPyFIEe9hepf
=HDZq
-----END PGP SIGNATURE-----
Eric Paris
> On Tue, Aug 31, 2010 at 17:49, Harald Hoyer <har...@redhat.com> wrote:
> > https://bugzilla.redhat.com/attachment.cgi?id=442223&format=raw
> >
> > udev/udev-node.c
> >
> > + /* set selinux file context on add events */
> > + if (strcmp(udev_device_get_action(dev), "add") == 0)
> > + udev_selinux_lsetfilecon(udev, file, mode);
>
>
> Does that makes sense/work for you?
> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=326c5fc3ea684825629eccaf33a548759162a539
>
> Kay
I ask Harald (but he wasn't around and I don't know the answer) if it is
a problem that this changes the behavior of non "add" events.
Previously a non "add" event with an incorrect mask/uid/gid would have
reset the SELinux context but now it will not. It fixes the issue at
hand, my boxes boot with everything labeled nicely, but I'm not sure if
there is some other corner case that expected the old behavior with
change events....
-Eric
Stephen Smalley
> On Tue, 2010-08-31 at 21:32 +0200, Kay Sievers wrote:
>> On Tue, Aug 31, 2010 at 17:49, Harald Hoyer <har...@redhat.com> wrote:
>> > https://bugzilla.redhat.com/show_bug.cgi?id=575128#c14
>> > https://bugzilla.redhat.com/attachment.cgi?id=442223&format=raw
>> >
>> > udev/udev-node.c
>> >
>> > + /* set selinux file context on add events */
>> > + if (strcmp(udev_device_get_action(dev), "add") == 0)
>> > + udev_selinux_lsetfilecon(udev, file, mode);
>>
>> I can't access these bugs.
>>
>> Does that makes sense/work for you?
>> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=326c5fc3ea684825629eccaf33a548759162a539
>>
>> Kay
>
> I ask Harald (but he wasn't around and I don't know the answer) if it is
> a problem that this changes the behavior of non "add" events.
> Previously a non "add" event with an incorrect mask/uid/gid would have
> reset the SELinux context but now it will not. It fixes the issue at
> hand, my boxes boot with everything labeled nicely, but I'm not sure if
> there is some other corner case that expected the old behavior with
> change events....
Maybe we should back up and ask the udev folks how they think libvirt
labeling should be done so as to not conflict with udev labeling, e.g.
should libvirt be going through udev to assign the labels.
Kay Sievers
> Maybe we should back up and ask the udev folks how they think libvirt
> labeling should be done so as to not conflict with udev labeling, e.g.
> should libvirt be going through udev to assign the labels.
The current idea is that udev only labels the device on bootup once,
or when a new device is discovered, and never changes it again (unless
someone will synthesize 'add' events, which should not happen).
The behavior described in the initial bug is just a plain udev bug.
With the fix Harald put in, it should behave as described above. That
can all be changed though, if needed, and if something else makes
sense.
Kay
Daniel J Walsh
Hash: SHA1
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majo...@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
>
>
Well I guess I would not want someone chcon a device and then udev
fixing the label. Especially on MLS machines.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkx+rQMACgkQrlYvE4MpobPAkQCgt93hFUhnv9wJONN+VN62L5c5
KzYAoKbijORf9iDwDazubFJOmAux/8wY
=BbqG
-----END PGP SIGNATURE-----