On Thu, Jan 9, 2014 at 4:27 PM, Peter Hutterer peter.hutterer@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@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@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.
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