Date: Tue, 6 Oct 2020 15:50:09 +0100 From: Simon McVittie <smcv@...ian.org> To: oss-security@...ts.openwall.com Subject: Re: major changes if gnu/linux dominates the desktop and/or mobile market? On Mon, 05 Oct 2020 at 19:30:22 -0400, Eli Schwartz wrote: > flatpak tries to provide a GUI appstore for popular applications in > sandboxes, with permission models for allowing resources into the > sandbox, e.g XDG Desktop Portal to broker access to files from the host > system through a trusted agent. > > Though my understanding is in order to be (conveniently?) usable, > programs end up in practice needing to be granted access to the entire > host filesystem and therefore aren't really isolated after all. It depends on the program. If it does its file access via the typical GTK or KDE File->Open and File->Save As... dialogs, then access to those files can be mediated by xdg-desktop-portal (the dialog exists outside the sandbox, and magics only the selected files into existence inside), and the boundary is quite strong. If the program does its file access by "knowing" that it has full access to everything, then, yes, you're going to have to give it access to everything it might conceivably need, statically, and the boundary is extremely leaky. The app framework cannot fix this, but maybe the app can. The developers of xdg-desktop-portal and related components have been doing what they can to make this transparent - for example, GTK 3 and 4 apps automatically use the portals for various things if they detect that they're in a Flatpak sandbox, so that app authors don't have to change how their app works. However, this is not always possible, and some years- or decades-old assumptions about access to the host system are harder to unpick. The other big problem with the Flatpak sandboxing model is X11, which just isn't a good privilege boundary: practical X11 apps assume that they can do things that ought to be only available to apps in the TCB. In GNOME this is mitigated by using Wayland by default, and Flatpak apps can be flagged to lose their X11 access when run under Wayland. I think KDE Plasma is heading in a similar direction. However, I suspect the audience of this mailing list contains a lot of the sort of people who either don't use GNOME or Plasma, or have switched GNOME or Plasma into X11 mode because Wayland breaks some feature that only ever worked because every X11 app trusts every other X11 app (such as screen-sharing by grabbing frames from the X server, or clever input-mapping tricks by injecting fake keyboard and mouse events into the X server, or screensavers that work in terms of X11 grabs). I don't know as many technical details of Snap and Firejail, but I'm fairly confident that they are running into the same problems that Flatpak does. I would encourage security experts who are interested in this field to "do their own homework" and research what has already been done, and what is already known to be a missing piece of the puzzle. A conversation on oss-security is not going to change any of this, however well-intentioned: some security experts making statements about how (GNU/)Linux desktops "need to change" does not get code written, does not shift apps away from un-sandboxable patterns and towards sandboxable patterns, does not fill in missing functionality in Wayland that will let people use as a more-sandbox-friendly alternative to X11, and so on. If you want to see the situation improve, please help to improve it. The people doing the work, at least in GNOME (and I'm sure elsewhere too), are mostly the same few overworked developers who are also maintaining all the other core parts of the desktop. > Apparently both giving power to the user *and* preventing software from > running rogue, is indeed hard. Yes, and harder still is retrofitting an app-store-like permissions model onto arbitrary programs that were originally designed to be run with full user privileges, without breaking them in the process. Again, Flatpak, Snap and Firejail are all attempts at this. They all have to make tradeoffs to be practically useful enough to be adopted, because a framework with perfect security and no working applications (or no users) is not practically useful. An additional threat here is that some of the same container and namespace tricks that we rely on to put up security boundaries between applications expose attack surface that can be exploited to break the security boundary between users (for example https://security-tracker.debian.org/tracker/source-package/bubblewrap, https://security-tracker.debian.org/tracker/source-package/firejail, and the attack surface referred to in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898446). 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.