linux-kernel - Re: selinux vs devtmpfs (vs udev)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 31 Aug 2010 16:39:22 +0200
From:	Harald Hoyer <harald@...hat.com>
To:	Daniel J Walsh <dwalsh@...hat.com>
CC:	Eric Paris <eparis@...hat.com>, Kay Sievers <kay.sievers@...y.org>,
	linux-kernel@...r.kernel.org, selinux@...ho.nsa.gov,
	greg@...ah.com, sds@...ho.nsa.gov
Subject: Re: selinux vs devtmpfs (vs udev)

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@...hat.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().
>>
> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/