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]
Message-ID: <4C7CC107.1050304@redhat.com>
Date:	Tue, 31 Aug 2010 10:44:55 +0200
From:	Harald Hoyer <harald@...hat.com>
To:	Eric Paris <eparis@...hat.com>
CC:	Kay Sievers <kay.sievers@...y.org>, linux-kernel@...r.kernel.org,
	selinux@...ho.nsa.gov, greg@...ah.com, sds@...ho.nsa.gov,
	dwalsh@...hat.com
Subject: Re: selinux vs devtmpfs (vs udev)

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

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ