Collaboration on standard Wayland protocol extensions
ppaalanen at gmail.com
Tue Mar 29 13:44:32 UTC 2016
On Tue, 29 Mar 2016 08:11:03 -0400
Drew DeVault <sir at cmpwn.com> wrote:
> On 2016-03-29 3:10 PM, Carsten Haitzler wrote:
> > > I don't really understand why forking from the compositor and bringing
> > > along the fds really gives you much of a gain in terms of security. Can
> > why?
> > there is no way a process can access the socket with privs (even know the
> > extra protocol exists) unless it is executed by the compositor. the compositor
> > can do whatever it deems "necessary" to ensure it executes only what is
> > allowed. eg - a whitelist of binary paths. i see this as a lesser chance of a
> > hole.
> 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. We can even look at /proc/exe and produce a
> checksum of it, so that programs become untrusted as soon as they
That means you have to recognize all interpreters, or you suddenly just
authorized all applications running with /usr/bin/python or such.
The PID -> /proc -> executable thing works only for a limited set of things.
However, forking in the compositor is secure against that. Assuming the
compositor knows what it wants to run, it creates a connection *before*
launching the app, and the app just inherits an already authorized
The general solution is likely with containers, as you said. That thing
I agree with.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 811 bytes
Desc: OpenPGP digital signature
More information about the wayland-devel