I've got 2 bugs now:
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
On Sat, Aug 28, 2010 at 01:00, Eric Paris <[email protected]> wrote:
> I've got 2 bugs now:
>
> 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.
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.
Kay
On Sat, 2010-08-28 at 11:57 +0200, Kay Sievers wrote:
> On Sat, Aug 28, 2010 at 01:00, Eric Paris <[email protected]> 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
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<[email protected]> 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().
-----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<[email protected]> 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.
-----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-----
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<[email protected]> 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?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/31/2010 10:39 AM, Harald Hoyer wrote:
> 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<[email protected]> 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?
>
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-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/31/2010 10:39 AM, Harald Hoyer wrote:
> 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<[email protected]> 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?
>
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-----
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<[email protected]> 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.
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
-----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<[email protected]> 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 [email protected] 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-----
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
On 08/31/2010 05:26 PM, Eric Paris wrote:
> 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);
On Tue, Aug 31, 2010 at 17:49, Harald Hoyer <[email protected]> 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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/31/2010 03:32 PM, Kay Sievers wrote:
> On Tue, Aug 31, 2010 at 17:49, Harald Hoyer <[email protected]> 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-----
On Tue, 2010-08-31 at 21:32 +0200, Kay Sievers wrote:
> On Tue, Aug 31, 2010 at 17:49, Harald Hoyer <[email protected]> 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....
-Eric
On 08/31/2010 09:32 PM, Kay Sievers wrote:
> On Tue, Aug 31, 2010 at 17:49, Harald Hoyer<[email protected]> 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
Exactly my patch :)