Re: Collaboration on standard Wayland protocol extensions

On Tue, 29 Mar 2016 08:11:03 -0400
Drew DeVault <sir 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  


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

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.


Attachment: pgpefVuzg7rtB.pgp
Description: OpenPGP digital signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]