[PULL to discuss] Remove kdrive, Xnest, and Xvfb

Jamey Sharp jamey at minilop.net
Tue Mar 27 07:35:08 PDT 2012


On 3/27/12, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
>> Date: Tue, 27 Mar 2012 06:03:03 -0700
>> From: Jamey Sharp <jamey at minilop.net>
>>
>> The key is to have a *non*-suid copy of the server available for those
>> who don't need root privs for their configuration. In that mode all
>> options can be processed without the server performing security
>> checks, and if you try to subvert system security the OS will stop
>> you.
>
> This is based on the (false) assumption that a suid Xorg is making
> things less secure.  It is perhaps somewhat non-intuitive, but a
> suid-root binary can use its powers to drop priviliges and become less
> priviliged than a normal user.  So a *non*-suid Xorg should not be a
> goal in itself.

Um... I can't say I'm convinced.

1) Why would you want to engineer the complexity of dropping privs,
with plenty of opportunities to get it wrong in ways that lead to root
holes? And since every OS has different rules about process
permissions, even getting it right on one kernel tells you nothing
about whether it's right anywhere else.

2) You aren't offering any advantage to an administrator--if a user's
X server is prohibited from doing some things the user is permitted to
do, you haven't stopped the user from doing them. So you must be
trying to support users who don't trust their X server and want to
sandbox it, right? But if they don't trust the X server, they
certainly shouldn't rely on it to sandbox itself, especially if it has
to have root permissions to do so.

By contrast, I think setting the server suid directly to an
unprivileged user would be fine, because it doesn't involve any
security-sensitive code in the server. Or using a dedicated program
that sets up restricted privileges, chroot, unshare, whatever
sandboxing you want, and then execs a plain copy of the X server,
because the code you have to audit then is small.

But no, I'm pretty sure keeping the X server away from root privs is
always the right thing, and we're just in a transition period where it
isn't always feasible yet.

Discussion of privilege is straying a bit far from the original topic,
but, well:
http://xkcd.com/386/

Jamey


More information about the xorg-devel mailing list