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]

Message-ID: <AANLkTi=aEdKM_hunJmPzXxPqkrbok+_C6QUKf8v=Q+18@mail.gmail.com>
Date:	Sat, 28 Aug 2010 11:57:26 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Eric Paris <eparis@...hat.com>
Cc:	linux-kernel@...r.kernel.org, selinux@...ho.nsa.gov,
	greg@...ah.com, sds@...ho.nsa.gov
Subject: Re: selinux vs devtmpfs (vs udev)

On Sat, Aug 28, 2010 at 01:00, Eric Paris <eparis@...hat.com> 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
--
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/