BSDs and wl_client_get_credentials

[Pekka Paalanen]

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:
> > I don't think we can fix wl_client_get_credentials(), the semantics are
> > very explicitly tied to the SO_PEERCRED behaviour. What I think we
> > should do instead is to look into making a new API using
> > SCM_CREDENTIALS.  
> 
> D-Bus uses (and needs) similar functionality, so if you learn from
> what D-Bus did, you can fast-forward past a lot of tedious portability
> discussions that we already had.

Hi Simon,

that is an excellent idea, thank you.


> > But could we make it return obviously invalid values?  
> 
> libdbus uses (pid_t) -1, (uid_t) -1 and (gid_t) -1 as the obviously-invalid
> values. On POSIX systems, the -1 values for uid_t and gid_t are not suitable
> for normal use due to their special meaning in setreuid() and setregid(), and
> negative PIDs are not suitable for normal use due to their special meaning in
> kill(), so that seems safe.

Hmm, -1 pid might actually be unsafe, if people don't expect that it
could be returned and may pass it to kill() to forcefully destroy a
client process. Seems there is no safe invalid value for pid wrt.
kill(), other than compositor's own pid which callers are expected to
filter out already.


> > 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. The security boundary between unconfined
> processes with the same uid is sufficiently nonexistent that this is unlikely
> to be viable without using LSMs (like Snap's use of AppArmor) and/or containers
> (like Flatpak's use of various namespaces).
> 
> Note that deriving information from the pid is easy to defeat if you have
> access to a mechanism like setuid or filesystem capabilities, which
> escalates capabilities while preserving the pid.
> See <https://bugs.freedesktop.org/show_bug.cgi?id=83499>.
> It can also be defeated by pid reuse, although that's a harder attack.
> 
> In Linux, SO_PEERCGROUP has been proposed but not accepted; if that
> existed then you'd be able to tell which cgroup the peer was in, for
> example on systemd systems.
> 
> On systems with LSMs (SELinux, AppArmor, etc.) you can use SO_PEERSEC
> to get the peer's LSM label, which is useful if your app framework uses
> LSMs (for example Snap does, but only on systems booted with AppArmor
> enabled).
> 
> Flatpak uses /proc/$pid/root/.flatpak-info as a roundabout way to discover
> which mount namespace the peer is in, which is not *perfectly* race-free
> (it can be defeated by pid reuse) but is believed to be good enough. It
> helps that Flatpak's D-Bus proxy is not under the control of the app,
> so it's hard (hopefully impossible?) to induce it to exit at just the
> right moment.
> 
> The D-Bus Containers1 interface (which I'm slowly working on as a replacement
> for Flatpak's D-Bus proxy) uses a separate listening socket per
> (app-)container, and requires the container framework to ensure that the
> confined app can't connect to the "global" D-Bus socket (as Flatpak already
> does).

That is enlightening. It makes me wonder what people are using
PID/UID/GID for.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190121/44dc6383/attachment.sig>