:: Re: [Dng] Device management [WAS: s…
Top Page
Delete this message
Reply to this message
Author: Jude Nelson
Date:  
To: Adam Borowski
CC: dng@lists.dyne.org
Subject: Re: [Dng] Device management [WAS: system scriptinng language.]
Hi Adam,

Good catch! The class of user-initiated runtime program alterations
(ptrace, LD_PRELOAD, LD_LIBRARY_PATH, different ld, etc) had slipped my
mind. This is why I'm having the conversation on vdev's core features
*before* the first alpha release, so design problems like this will get
caught early :)

I think setuid combined with vdev presents an interesting possibility:
what if we changed X from setuid-root to setuid-daemon (or setuid-nobody,
or whatever), and used a variant of the above stanza to grant it access to
the privileged device nodes it needs? This would allow X to run as a
less-privileged user than even the user that started it, while ensuring
that it can access the necessary device files. So, the setup would become
as follows:

$ ls -l /usr/bin/X
-rwsr-sr-x 1 daemon daemon 10104 Apr 1 2014 /usr/bin/X

$ cat /etc/vdev/acls/X11.acl
[vdev-acl]
uid=daemon
gid=daemon
bin=/usr/bin/X
paths=input/.*|dri/.*
setmode=0666

In the absence of any ACLs that add permissions for /dev/dri/* and
/dev/input/*, this vdev-acl stanza would ensure that only a process running
as user daemon and group daemon whose binary is located at /usr/bin/X will
see /dev/dri/* and /dev/input/* with permission bits 0666. You could
(should) take additional filtering measures, such as adding "pidlist=cat
/paths/to/X11/pid/files" to ensure that only the running X servers that
have written their PID files already will see /dev/dri/* and /dev/input/*
as read/write.

DISCLAIMER: I have *not* tested this yet, but it should work so long as
the only reason X otherwise needs to run as root is because the device
nodes under /dev/input/ and /dev/dri/ are necessarily unreadable and
unwritable for users outside the root user and input and video groups
(respectively). It is my understanding that the advent of KMS already
allows X to run without privileges as long as it can access the right
device files (the problem vdev solves), but for multi-user systems the very
same device files must be inaccessible to unprivileged users because they
expose input and graphics data from other users' graphical sessions.
Please correct me if I'm wrong :)

-Jude


On Wed, Dec 31, 2014 at 12:35 AM, Adam Borowski <kilobyte@???> wrote:

> On Sun, Dec 28, 2014 at 10:52:38PM -0500, Jude Nelson wrote:
> > Here's a more practical example that hides /dev/input/* and /dev/dri/*
> from
> > every program except the X server (installed to /usr/bin/X):
> >
> > [vdev-acl]
> > bin=/usr/bin/X
> > paths=input/.*|dri/.*
> > setmode=0666
>
> This seems broken to me... as in, the very idea you can trust a process
> because of its executable will give people a false sense of security.
>
> If a process runs with your uid, you can have it do anything you do want
> by a number of methods. You can ptrace it, LD_PRELOAD, use a ld of your
> own, etc.
>
> The only way to secure this is to use setuid, but then, you already have
> a better way selector to build the ACL on.
>
> Thus, I think you'd be better off without bin= stanzas.
>
> --
> // If you believe in so-called "intellectual property", please immediately
> // cease using counterfeit alphabets. Instead, contact the nearest temple
> // of Amon, whose priests will provide you with scribal services for all
> // your writing needs, for Reasonable and Non-Discriminatory prices.
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>