Date: Mon, 19 Oct 2020 21:21:39 +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, 19 Oct 2020 at 13:22:49 +0200, Solar Designer wrote: > So let's accept that the user account running the desktop environment is > root-equivalent security-wise (is only different from root for safety, > not security) as long as it's ever used to reach root. If you want to isolate apps from each other, then I think there are really two sets of security boundaries: * The system: Between user A, user B and root - root and root-equivalent users are in the TCB for this set of security contexts - some system services like polkit and dbus-daemon --system are typically also in the TCB * Per-user: Between user A's app 1, user A's app 2, and user A's desktop - user A's desktop is in the TCB for this set of security contexts - user A's desktop includes their window manager/compositor, dbus-daemon --session, PulseAudio or PipeWire, etc. and it's possible for a program to be in the TCB for neither of those, for both of those, or for just the per-user boundary (meaning the desktop environment of an unprivileged user). The Apertis automotive OS is an example of a similar model in a non-desktop context, heavily based on how these things work in "freedesktop" OSs. https://www.apertis.org/designs/security/#security-boundaries-and-threat-model > Yes, the most difficult part with securing a desktop system is to keep > it conveniently usable. I think it is possible to isolate the desktop > environment from user programs without inconveniencing the user. As to > isolation between the user's programs, yes, that becomes visible to the > user and would require some training on how to explicitly transfer data > between the programs when needed. Flatpak does this by having each Flatpak app in a (separate) sandbox. Communication between apps goes through components in what you might call the desktop TCB (trusted by this user, but not necessarily by the sysadmin), such as the Wayland compositor, dbus-daemon --session, and xdg-desktop-portal. There are various tricks for making crossing the sandbox boundary automatic while preserving user control. For example, if you do File->Open... in a Flatpak app, the Open dialog that pops up is part of the trusted desktop session, not part of the app itself (so it can see all your files). On choosing a file to open, that file - but none of other files that you declined to open - appears in the sandbox (on a FUSE filesystem). I think Snap uses xdg-desktop-portal in a similar way. Qubes would not be able to use it unmodified, because its isolation between contexts is "heavier" (virtualization rather than containers), but it could certainly use similar concepts. > "Containerizing" things (at best) protects the outside from what's > contained, not vice versa. Right. In an OS that makes heavy use of Flatpak, like Endless, basically all the user-facing apps are in Flatpak sandboxes (containers). Anything that is not sandboxed (like desktop configuration), or is in a sandbox that cannot provide a meaningful security boundary because that would defeat the purpose of the program (like file managers, development tools and sysadmin tools), is effectively part of the TCB of the desktop. 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.