On Nov 2, 2015 7:05 AM, "Adam Jackson" <ajax(a)redhat.com> wrote:
On Fri, 2015-10-30 at 14:58 -0700, Andrew Lutomirski wrote:
> On Fri, Oct 30, 2015 at 2:48 PM, Adam Jackson <ajax(a)redhat.com> wrote:
> > Anyone running any X (or wayland) application as root in their desktop
> > session is completely bonkers and deserves every consequence of their
> > poor decision.
> OK, I'll bite. Why is it bonkers?
> It's certainly the case that *gnome* might do something ridiculous if
> you 'sudo gedit' something, but 'sudo emacs' really ought to be
> equally acceptable regardless of whether you're using the terminal or
> X frontend.
Same reason you probably don't want to run your irc client as root:
you're trusting the server to be well-behaved, through code that isn't
expecting to need to do input validation. Consider this class of
Also, at least under X, you're trusting _every other app in the
session_ to politely ignore the privileged client. There's nothing to
stop another client from blitting a deceptive image into the privileged
window, or from creating input-only children of the privileged window
and stealing its keystrokes (and forwarding them on to the privileged
app however it sees fit, which might not be unmodified).
You have the same problem with root-equivalent polkit rights.
This is all somewhat hypothetical, granted. Certainly one can
construct scenarios where it'd be safe enough. Probably there's
selinux policy for X that could fix this kind of abuse, and wayland has
a much smaller surface for this class of bug to sneak through.
We're talking about Wayland, though.
But, why take the risk exposure, when you could simply not?
> ISTM the straightforward solution to all of this would be for Wayland
> to allow a connection from anyone who can connect to the socket. Then
> just set permissions on the socket accordingly.
Unless I'm missing something, there's no way to set permissions on a
unix socket such that root (or anyone else with CAP_DAC_OVERRIDE) is
Root can connect one way or another and you can't do anything to prevent
it. The socket DAC/ACL approach lets users set their own policy (e.g.
Android-like things where maybe a gid is the right thing to check), and
while discouraging root GUI may make sense, actively trying to prevent it
seems both user-hostile and futile.