BSDs and wl_client_get_credentials

[Simon McVittie]

On Mon, 21 Jan 2019 at 14:40:23 +0200, Pekka Paalanen wrote:
> On Mon, 21 Jan 2019 11:35:12 +0000
> Simon McVittie <smcv at collabora.com> wrote:
> > On Mon, 21 Jan 2019 at 12:40:11 +0200, Pekka Paalanen wrote:
> > > Currently I have no clear opinion on what might be best. PID, UID and
> > > GID are quite poor for authorization anyway, I wish we could identify
> > > some more... fine-grained? At the application level? But is there even
> > > a useful definition of "an application" from the kernel point of view?  
> > 
> > Not really. To implement that, you'd need a race-free way to determine what
> > "application" your peer is part of. [...]
>
> That is enlightening. It makes me wonder what people are using
> PID/UID/GID for.

The uid makes a lot of sense *if* you are a security boundary between uids
(like the D-Bus system bus). Is the concept of a Wayland system compositor
still a thing? If it is, then uids are the first/highest level of being able to
distinguish between clients. The next level down is probably the trusted
computing base (TCB: all the trusted OS components, as a monolithic unit) vs.
sandboxed "apps" (Flatpak or Snap or similar), and below that you can start
distinguishing between different "apps".

If your Wayland compositor only serves one user (like GNOME Shell), then
a good use for the uid is "immediately disconnect anyone whose euid is
not me", like the D-Bus session bus does. If you do that, then
tautologously every surviving connection has the same euid, and the only
interesting boundaries are between TCB and "apps", and below that, between
one "app" and another.

Current Linux systems don't really put a useful security boundary between
OS-provided apps in /usr - they can all ptrace each other, they can all induce
each other to execute arbitrary code by overwriting ~/.config or ~/.bashrc or
some other well-known trusted file or by communicating over D-Bus, and so on -
so they're effectively all part of the trusted computing base. Technical users
rely on the fact that these apps all trust each other, too: xterm is an "app",
and so is emacs, but you'd be upset if you found that emacs wasn't allowed to
edit the ~/.bashrc that controls the shell in your xterm, or that your xterm
session isn't allowed to edit the files that are read by emacs.

That's why container-based app systems like Flatpak and LSM-based app systems
like Snap exist: their extra security boundaries give us a way to draw a line
between the TCB (including the compositor, the desktop session's configuration
UI like gnome-control-center, other desktop session bits like dbus-daemon and
gnome-settings-daemon, the terminal and other development tools, etc.), and the
rest of the app world.

I'm writing from the perspective of Linux and GNOME because that's what I use,
but the same is broadly true in all the non-Linux and non-GNOME "freedesktop"
environments, with some relabelling (for instance KDE clearly doesn't have
gnome-control-center, but it presumably has some other UI for global desktop
settings, which has essentially the same requirements as gnome-control-center
in terms of what it needs to be allowed to do).

Non-Linux systems obviously don't have the Linux-specific namespace-based
containers and LSMs, but if BSD users want sandboxed apps that are not in the
TCB, they presumably also have to use either something analogous to a Linux
container (jails?), or some DAC mechanism analogous to an LSM (Capsicum?), to
arrange for the sandboxed app to be prevented from affecting the TCB in ways
that it shouldn't.

Android uses an interesting hack to distinguish between "apps" securely: it
allocates a block of uids for each user account instead of a single uid,
allocates one uid per user account per "app", and runs each "app" under its
appropriate uid. This is not straightforward to retrofit onto an existing
ecosystem like the Unix/X11/Wayland/freedesktop stack, though: it only works
because Android is its own independent ecosystem from a UI and app development
point of view.

    smcv