Hi Enrico,

> Actually, I think we should get rid of suid at all.

As much as I would like to do this, Adam raised the excellent point that
setuid programs can't be traced or LD_PRELOAD'ed by unprivileged users.
This is critical for safe device access, since the whole point of vdev
equivocating about device permissions is to ensure that only processes that
are trusted not to do Bad Things are allowed to see device nodes under
vdev's control. If we allow the user insert code that does Bad Things into
processes that vdev otherwise trusts, then it's all for naught.

>From a security perspective, setuid can be a good thing, since you can
ensure that the effective UID/GID matches a known-unprivileged user (like
daemon, or nobody) as well, instead of a known privileged user (root).

> Instead have separate users for individual X displays (or "seats"),
> and give these users appropriate permissions to the required devices.
> Then it would be the task of the display manager (or whoever starts
> the X servers) to switch to the correct UID. The same entity would
> be responsible for controlling the X auth tokens and socket locations.

I would imagine that you could have a login script or PAM module that sets
this all up for you, so you could keep it decoupled from a specific display
manager or GUI implementation :)

> I just had a little experiment - tried to run the Xserver as an
> unprivileged user (after giving him access to devices, logfiles, etc),
> but still got permission denied (not for the open(), but individual
> ioctl()s) and it left the tty's in broken state (console lockup when
> switching there).

Thanks for giving this a try! I haven't tried it myself yet, but I'll do
so as soon as I can (I've seen it work on other machines, though). Do you
know which specific ioctl()s failed? What video card and driver are you
using? Are you sure KMS is enabled? Which X server version are you
running?

Thanks,
Jude

On Wed, Dec 31, 2014 at 7:14 AM, Enrico Weigelt, metux IT consult <
enrico.weigelt@???> wrote:

> On 31.12.2014 07:48, Jude Nelson wrote:
>
> Hi,
>
> > 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:
>
> Actually, I think we should get rid of suid at all.
>
> Instead have separate users for individual X displays (or "seats"),
> and give these users appropriate permissions to the required devices.
> Then it would be the task of the display manager (or whoever starts
> the X servers) to switch to the correct UID. The same entity would
> be responsible for controlling the X auth tokens and socket locations.
>
> > 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
>
> I just had a little experiment - tried to run the Xserver as an
> unprivileged user (after giving him access to devices, logfiles, etc),
> but still got permission denied (not for the open(), but individual
> ioctl()s) and it left the tty's in broken state (console lockup when
> switching there).
>
> Linux version 3.13.0-39-generic (buildd@roseapple) (gcc version 4.8.2
> (Ubuntu 4.8.2-19ubuntu1) ) #66-Ubuntu SMP Tue Oct 28 13:31:23 UTC 2014
>
> Seems it doesn't work properly yet (at least on my kernel version)
>
>
> cu
> --
> Enrico Weigelt,
> metux IT consulting
> +49-151-27565287
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>