On Wed, 28 Jul 2021 at 18:22:55 +0100, Carsten Haitzler wrote:
> but in the end almost everyone wants some way to differentiate what clients
> can
> and cannot do based on some kind of sandboxing and rules.
Before that can happen, you need a concept of identity: you can't say
anything about what a client can or cannot do unless you can say which
client it is. D-Bus, X11 and other AF_UNIX protocols have the same problem.
You can get the euid from Linux SO_PEERCRED or SCM_CREDENTIALS, or other
OSs' equivalents. D-Bus, X11 and Wayland already do this. Each OS does this
differently but there's fairly wide coverage.
You can get the primary egid (but only the primary one!) from Linux
SO_PEERCRED or SCM_CREDENTIALS, or most other OSs' equivalents. D-Bus,
X11 and Wayland already do this.
You can get the supplementary groups from Linux SO_PEERGROUPS. At least
D-Bus already does this. I am not aware of non-Linux implementations,
but maybe some of the BSDs have a corresponding feature.
On Linux systems with some LSMs (SELinux, SMACK, or AppArmor with Ubuntu's
(non-upstreamed?) kernel patches) you can get the LSM security context
from SO_PEERSEC, but this only helps if your apps all have unique LSM
labels. D-Bus does this too.
Linux SO_PEERCGROUP and SO_PEERPIDFD have been proposed, but as far as I
know they are not in the upstream Linux kernel.
As noted elsewhere in this thread, process IDs can be retrieved reliably
from the same mechanisms as the euid, but reading extra information
from /proc/$pid/ is prone to race conditions and cannot (in general)
be done safely. SO_PEERPIDFD might defeat those attacks.
Flatpak deals with these attacks in D-Bus by using a separate, trusted
proxy process per Flatpak app, which is not under the control of the
Flatpak app, but has a marking (/proc/$pid/root/.flatpak-info) that can
be used to identify which Flatpak app it is acting on behalf of. Because
the proxy is not under the control of the Flatpak app, the Flatpak
app cannot force it to do what is needed to carry out the pid-reuse
attacks[0]. Similarly, Flatpak apps are sandboxed with seccomp, mount
namespaces and NO_NEW_PRIVS to make it difficult (hopefully impossible)
for them to alter their /.flatpak-info. This is all Linux-specific and
concerningly subtle, but probably good enough until the kernel provides
the building blocks to make something better implementable.
The approach typically used in e.g. GNOME is that Flatpak apps are treated
as semi-untrusted, but apps that are not in a container (in the main OS)
are treated as essentially part of the TCB[1], because in practice they have
the ability to subvert trusted processes (e.g. overwriting ~/.bashrc, or
dconf settings, or the login session's LD_PRELOAD or LD_LIBRARY_PATH,
and using that access to execute arbitrary code).
Ubuntu does a similar thing with AppArmor, treating typical end-user
applications (and in particular many Snap apps) as untrusted, but treating
things like an interactive terminal as part of the TCB.
smcv
[0] assuming the Flatpak app's permissions are not broad enough to allow
arbitrary code execution / sandbox escapes; if they are, then you have
already lost
[1] https://en.wikipedia.org/wiki/Trusted_computing_base;
for more useful terms, see also a design document I wrote for an
automotive OS that has the same multiple layers of security boundary
as a typical Linux desktop with e.g. Flatpak or Snap, namely:
* security boundary between the OS/system services and all users;
* security between one user and another
* security between two apps owned by the same user
https://www.apertis.org/concepts/security/#security-boundaries-and-threat-model
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
