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.