On Tue, 28 Mar 2017 14:31:24 +0300 Pekka Paalanen <ppaala...@gmail.com> said:
> 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 Just saying... it's the first (and best) idea that comes to mind. We use SMACK in Tizen to sandbox apps. But I am sure others will use other schemes. If every OS/distro has some other sandboxing scheme it'll be REALLY hard for compositors to be portable as they then have to support every possible security scheme to auth privileged clients. If i make the assumption that a sandboxing scheme will at a minimum disallow apps that are not meant to have access to the environment of a process to read it (i.e. /proc/PID/environ), and that an app given a cookie will be careful not to pass it on (via publicly readable files, IPC, or execution) to other apps it does not also trust as much as itself... Then an environment variable actually works nicely. An app can read it then putenev()/unsetenv() it after it's already been used or stored elsewhere (or before forking+executing anything untrusted). This should work irrespective of the MAC/sandboxing mechanism and thus would provide some kind of method "we all agree on" for granting some kind of privileges to some client. If there is a better idea, please do share. This is not necessarily the best. It's just the best one that popped int my little head. :) > env, until something better comes around. Also the restrictions and I think that we should specify the environment variable much like XDG does too. If it is otherwise shared via another mechanism, at least for now that could be "implementation defined" based on the sharing/IPC protocol or whatever between those processes. > 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. I see no reason why a compositor can't impose EXTRA restrictions like the above. E.g. check cookie AND then also check client container or smack label or... whatever. So if the cookie leaked outside of this sandbox it would be invalid anyway. Each cookie can indeed also represent different access privileges so a cookie would only at best grant access to what it was intended to gain access to and nothing more (if the compositor did it right). > So now we need a spec for the cookie. An opaque binary blob with > variable size, limited by some maximum size? 1 kB max? I'm pretty agnostic on what it is. I might lean to a string, not a binary blob. Because This is easily embedded in an environment variable as-is. I would suggest that the compositor use something like a SHA256 hash and then base64 encode it (so it'd end up being 48 bytes of a string + 0 byte). But perhaps an opaque binary blob in protocol and define the environment variable to be a base64 encoding of that?... or hex? ... > (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. I would agree with making it optional if the compositor can determine some other way that this request from a client (dbnus, wl protocol... doesn't matter) is already allowed. I really just want us to have a "single mechanism" we can agree on for doing this that isn't OS dependent and "unportable". I still would lean to, for now, defining an environment variable as that's a pretty basic guarantee of at least 1 way to get it. Any user who can get a cookie from their compositor can "empower" their shell with an easy: export WL_PRIV_COOKIE="77fa767c28c73782988910eee0abcd8824894" or whatever. :) > 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? > > > Thanks, > pq -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel