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. Canwhy? 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 change.
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 connection. The general solution is likely with containers, as you said. That thing I agree with. Thanks, pq
Attachment:
pgpefVuzg7rtB.pgp
Description: OpenPGP digital signature