Collaboration on standard Wayland protocol extensions

[Simon McVittie]

On 29/03/16 13:11, Drew DeVault wrote:
> I see what you're getting at now. We can get the pid of a wayland
> client, though, and from that we can look at /proc/cmdline, from which
> we can get the binary path.

This line of thinking is a trap: rummaging in /proc/$pid is not suitable
for use as a security mechanism. If a client can queue up a malicious
privileged action (stuff it into the socket's send-buffer), and then
race with the compositor to exec() something that would legitimately be
allowed to take that action before the request is processed, then you lose.

See <https://bugs.freedesktop.org/show_bug.cgi?id=83499> for details of
the equivalent in D-Bus. Mainline dbus on Unix was never vulnerable to
this (because we use credentials-passing to get the uid), but there used
to be an out-of-tree LSM integration patch set (for Maemo) that was.
(That bug was about documenting the attack so that we never accidentally
introduce it.)

If you want to map processes to executable-based privilege domains in a
way that cannot be faked, you will have to use their LSM labels
(SELinux, Smack or other xattr-based labelling, or AppArmor or other
path-based labelling) which are specifically designed to do this. A
Wayland equivalent of D-Bus' GetConnectionCredentials() would probably
be useful.

    S
-- 
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>