[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwin
Subject:    Re: Collaboration on standard Wayland protocol extensions
From:       Pekka Paalanen <ppaalanen () gmail ! com>
Date:       2016-03-29 13:44:32
Message-ID: 20160329164432.3491aebd () eldfell
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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  
> > 
> > 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

[Attachment #5 (application/pgp-signature)]
[Attachment #6 (text/plain)]

_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin


[prev in list] [next in list] [prev in thread] [next in thread]