[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] major changes if gnu/linux dominates the desktop and/or mobile market?
From:       Simon McVittie <smcv () debian ! org>
Date:       2020-10-19 20:21:39
Message-ID: 20201019202139.GA30622 () espresso ! pseudorandom ! co ! uk
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]