[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
