On Wed, Mar 29, 2017 at 9:33 AM, Jordan Sissel <j...@semicomplete.com> wrote:
On Tue, Mar 28, 2017 at 2:44 PM, Christopher James Halse Rogers < christopher.halse.rog...@canonical.com> wrote: On Tue, 28 Mar 2017 at 22:31 Pekka Paalanen <ppaala...@gmail.com> wrote: On Tue, 28 Mar 2017 16:20:28 +0900 Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote: > On Wed, 22 Mar 2017 13:59:43 +0200 Pekka Paalanen <ppaala...@gmail.com> said: > > > > == Authentication/Identification == > > > The goal is to filter clients based on some white/blacklist, so that e.g. > > > xdotool can access this interface but others cannot. > > > > Hi, > > > > if one allows a generic tool that essentially exposes everything at > > will, there isn't much point in authenticating that program, because > > any other program can simply call it. > > This is where right now I might lean to some environment variable with a > cookie/key the compositor provides *and that may change from session to session > or on demand). > > So compositor might putenv() then fork() + exec() something like a terminal > app.. and then this terminal app and anything run from it inherits this env > var... and thus now has the secret key to provide... > > This also allows the compositor to run any such process that passes the > key/cookie along to other processes/tools it determines are safe. It would > require the compositor have a "safe user initiated or approved" way to run such > things. Hi, that doesn't sound too bad. Initially the cookie could be passed in the env, until something better comes around. Also the restrictions and privileges carried with a cookie could vary based on how it was generated, e.g. cookies created for a container could be invalid for clients outside that specific container. Or require matching to SElinux or SMACK or whatever attributes. Or none of these at first. Completely up to the compositor. So now we need a spec for the cookie. An opaque binary blob with variable size, limited by some maximum size? 1 kB max? (To ensure e.g. Wayland can relay the maximum sized cookie in one message.) This could be the generic starting point for all privileged interfaces, Wayland and others. How the client will get the cookie in the first place is left undefined. The cookie should probably be optional too, in case another scheme already grants the privileges. Giulio, how about incorporating such a cookie scheme in your restricted_registry design? OTOH, a spec that uses cookies but does not tell where you might get one, is that useful? Do we have to spec the env variable? FWIW, an HMAC cookie is how we handle various privileged actions in Mir (raise window, drag & drop [because most of D&D is handled out-of-compositor]), so this would be easy to integrate for us. I am interested in the security concerns here, but are there reliable barriers between different processes run by the same user in the same desktop session? What is the threat model y'all are defending against? At least on Ubuntu ptrace is restricted to child processes or root, so while a malicious process could potentially attack a privileged process via crafted input it's not a simple matter of attaching a debug probe to it. Also there's the migration(ish) to applications distributed via flatpak and snap, both of which provide robust (at least under Wayland/Mir) isolation from each other and the general system. So, at least one threat model is “we're going to download and run arbitrary code from the internet, and it shouldn't be able to surreptitiously spawn a terminal and exfiltrate our GPG keys”.
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel