Should /usr/bin/Xorg (still) be setuid-root?

[Andrew Lutomirski]

On Thu, Jan 9, 2014 at 4:27 PM, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> On Thu, Jan 09, 2014 at 12:52:46PM -0800, Andrew Lutomirski wrote:
>> On Thu, Jan 9, 2014 at 11:43 AM, Hans de Goede <hdegoede at redhat.com> wrote:
>> > Hi,
>> >
>> >
>> > On 01/09/2014 12:09 AM, Andrew Lutomirski wrote:
>> >>
>> >> On Wed, Jan 8, 2014 at 2:58 PM, Peter Hutterer <peter.hutterer at who-t.net>
>> >> wrote:
>> >>>
>> >>> On Wed, Jan 08, 2014 at 01:14:08PM -0800, Andrew Lutomirski wrote:
>> >>>>
>> >>>> /usr/bin/Xorg is, and has been, setuid-root just about forever.  I'm
>> >>>> wondering whether there's any good reason for it to remain
>> >>>> setuid-root.
>> >>>
>> >>>
>> >>> http://fedoraproject.org/wiki/Changes/XorgWithoutRootRights
>> >>
>> >>
>> >> This isn't actually the same thing.  That proposal suggests running
>> >> Xorg as a non-root user.  I'm proposing dropping the setuid bit on the
>> >> binary, which will have no effect on the uid of the running server.
>> >> (Of course, my suggestion will interact w/ that change, since the
>> >> process that starts Xorg will no longer be root.)
>> >
>> >
>> > I don't think that that will be very useful, it will likely cause more
>> > breakage then you think, as various display-managers may already start
>> > Xorg inside the user session, at which point the suid bit is needed,
>> > and as you already said it will break xinit and friends.
>>
>> This is an empirical question :)  gdm on F20, at least, can still
>> switch users with the setuid bit cleared.  I'll try to test some more
>> display managers.
>>
>> >
>> > Besides that almost every Fedora system already has a copy of the X
>> > server running as root ready to be exploited. The attack service of
>> > X is not its cmdline or attacks through environment settings
>> > (2 vectors your suggestion would close), but rather the gargantuan
>> > API it exposes over the X protocol itself.
>> >
>>
>> There's currently a big attack surface if I run some daemon that gets
>> remotely pwned -- the attacker could start a brand new X server and
>> try to exploit it.  On the other hand, they'd have a much more limited
>> attack surface against the already running daemon, because they'll
>> have trouble getting past the X authentication checks.
>>
>> >
>> >> It may be that XorgWithoutRootRights will clear the setuid bit as well,
>> >> though.
>> >
>> >
>> > Hopefully, either clear it completely or drop root rights very early
>> > on on startup.
>>
>> I hope it clears the bit -- I really don't like the fact that 'X :1'
>> screws with the display.
>
> You understand that this isn't as much screwing with the display as being a
> base functionality of the x server? It's a bit like saying starting apache
> screws with your port 80 when you start it.

Except that apache doesn't screw with your port 80 if you try to start
it as nonroot :)  In a similar vein, chvt doesn't work unless you're
root.  I don't see why X should be special, other than for rather old
historical reasons.

I'm pretty sure that the last time I tried to use 'startx' was when I
sat down directly in front of the SPARCstation because other people
were using all X terminals.  Even then, most of the time I'd be
sitting at the X terminal with a xterm and nothing else, and I'd just
run an mwm session instead of running a whole X server.  Of course,
back then my password was sent over the network as clear text every
time I typed it.  No one needed to pwn an X server -- you could get
anyone's password by leaving a fake getty running on the modem pool.

It would be possible to arrange for running Xorg to still work if
you're in a new xorg group.

--Andy