On Mon, 21 Jan 2019 11:35:12 +0000 Simon McVittie <[email protected]> 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
pgpO9NUV8xMgD.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
