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:	Wed, 1 Sep 2010 12:08:55 -0400
From:	Stephen Smalley <stephen.smalley@...il.com>
To:	Eric Paris <eparis@...hat.com>
Cc:	Kay Sievers <kay.sievers@...y.org>,
	Harald Hoyer <harald@...hat.com>,
	Daniel J Walsh <dwalsh@...hat.com>,
	linux-kernel@...r.kernel.org, selinux@...ho.nsa.gov,
	greg@...ah.com, sds@...ho.nsa.gov
Subject: Re: selinux vs devtmpfs (vs udev)

On Tue, Aug 31, 2010 at 4:51 PM, Eric Paris <eparis@...hat.com> wrote:
> On Tue, 2010-08-31 at 21:32 +0200, Kay Sievers wrote:
>> On Tue, Aug 31, 2010 at 17:49, Harald Hoyer <harald@...hat.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.
--
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/