Collaboration on standard Wayland protocol extensions

[Pekka Paalanen]

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
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160329/0c77697e/attachment.sig>