[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 11 Jul 2019 16:56:23 +0100
From: Simon McVittie <smcv@...ian.org>
To: oss-security@...ts.openwall.com
Subject: Re: Privileged File Access from Desktop Applications
On Thu, 11 Jul 2019 at 09:33:26 -0400, Perry E. Metzger wrote:
> if you logged in as root, you could run GUI applications as root
Yes, that is my understanding. Apps run as uid N trust uid N's Wayland
compositor, and uid N's Wayland compositor allows connections by apps
run as uid N and rejects all others. This is approximately the same
security policy as an Xorg X11 server with "xhost +si:localuser:USERNAME"
(and nothing else that would allow access, e.g. no xauth(1) tokens).
Logging in to a typical graphical desktop environment as root is probably
*also* a bad idea, because a full desktop environment is a huge attack
surface to be running with a complete set of capabilities; but it does
avoid some of the problems that come with running individual applications
as root.
Graphical toolkits typically (have to!) trust their X11/Wayland display
(to not send them forged input events, if nothing else), but an app
running as uid 0 has no good reason why it should trust an X11 server
or Wayland compositor running as uid 1000. By sending appropriate input
events, the X11 server or Wayland compositor can make the app do anything
for which it has UI. This makes the privilege boundary between uid 1000
and uid 0, when a user with uid 1000 will escalate privileges to uid 0,
somewhat illusory.
If the graphical toolkit or app was not designed to be robust against
a malicious display server, or if it was designed to be robust against
a malicious display server but has bugs in the implementation of that
design, then the user might also be able to subvert the app, escalating
from limited root privileges (for example a GUI running as root for
network configuration, which allows network configuration within certain
parameters) to unlimited root privileges (arbitrary code execution).
Similarly, if we want accessibility features (screen readers, magnifiers,
on-screen keyboards, alternative input methods, etc.), then graphical
toolkits have to trust the accessibility provider, but an app running
as uid 0 doesn't really have any good reason to be trusting accessibility
technologies running as uid 1000 either.
In X11, there is also the problem that every client (app) can usually spy
on the input and output of every other client, and fake input into every
other client, which means compromising any app compromises every app.
Wayland doesn't generally have that, because only special privileged
connections are normally allowed to take screenshots, receive input while
not in focus, or forge input events (but note that these connections
are privileged within the context of a desktop session, not privileged
within the context of the overall system).
smcv
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
