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 <kilob...@angband.pl> 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@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
