On Tue, 29 Mar 2016 08:11:03 -0400 Drew DeVault <[email protected]> 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 > 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
pgpCcEjGa9KaX.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
