<div dir="ltr"><div id="m_-5329575048675459662geary-quote" class="gmail_msg">On Wed, Mar 29, 2017 at 9:33 AM, Jordan Sissel <<a href="mailto:jls@semicomplete.com" class="gmail_msg" target="_blank">jls@semicomplete.com</a>> wrote:<br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div dir="ltr" class="gmail_msg"><br class="gmail_msg"><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg">On Tue, Mar 28, 2017 at 2:44 PM, Christopher James Halse Rogers <span dir="ltr" class="gmail_msg"><<a href="mailto:christopher.halse.rogers@canonical.com" class="gmail_msg" target="_blank">christopher.halse.rogers@canonical.com</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><div class="m_-5329575048675459662h5 gmail_msg"><div dir="ltr" class="gmail_msg">On Tue, 28 Mar 2017 at 22:31 Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com" class="gmail_msg" target="_blank">ppaalanen@gmail.com</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, 28 Mar 2017 16:20:28 +0900<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
Carsten Haitzler (The Rasterman) <<a href="mailto:raster@rasterman.com" class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg" target="_blank">raster@rasterman.com</a>> wrote:<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
> On Wed, 22 Mar 2017 13:59:43 +0200 Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com" class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg" target="_blank">ppaalanen@gmail.com</a>> said:<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
><br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
> > > == Authentication/Identification ==<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
> > > The goal is to filter clients based on some white/blacklist, so that e.g.<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
> > > xdotool can access this interface but others cannot.<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
> ><br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
> > Hi,<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
> ><br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
> > if one allows a generic tool that essentially exposes everything at<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
> > will, there isn't much point in authenticating that program, because<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
> > any other program can simply call it.<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
><br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
> This is where right now I might lean to some environment variable with a<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
> cookie/key the compositor provides *and that may change from session to session<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
> or on demand).<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
><br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
> So compositor might putenv() then fork() + exec() something like a terminal<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
> app.. and then this terminal app and anything run from it inherits this env<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
> var... and thus now has the secret key to provide...<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
><br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
> This also allows the compositor to run any such process that passes the<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
> key/cookie along to other processes/tools it determines are safe. It would<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
> require the compositor have a "safe user initiated or approved" way to run such<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
> things.<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
Hi,<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
that doesn't sound too bad. Initially the cookie could be passed in the<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
env, until something better comes around. Also the restrictions and<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
privileges carried with a cookie could vary based on how it was<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
generated, e.g. cookies created for a container could be invalid for<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
clients outside that specific container. Or require matching to SElinux<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
or SMACK or whatever attributes. Or none of these at first. Completely<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
up to the compositor.<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
So now we need a spec for the cookie. An opaque binary blob with<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
variable size, limited by some maximum size? 1 kB max?<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
(To ensure e.g. Wayland can relay the maximum sized cookie in one<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
message.)<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
This could be the generic starting point for all privileged interfaces,<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
Wayland and others. How the client will get the cookie in the first<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
place is left undefined. The cookie should probably be optional too, in<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
case another scheme already grants the privileges.<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
Giulio, how about incorporating such a cookie scheme in your<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
restricted_registry design?<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
OTOH, a spec that uses cookies but does not tell where you might get<br class="m_-5329575048675459662m_5128158739054045702gmail_msg gmail_msg">
one, is that useful? Do we have to spec the env variable?<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div class="gmail_msg">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.<br class="gmail_msg"></div></div></div>
</blockquote></div><br class="gmail_msg"></div><div class="gmail_extra gmail_msg">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?<br class="gmail_msg"></div></div></blockquote><br class="gmail_msg"></div><div id="m_-5329575048675459662geary-quote" class="gmail_msg"><div class="gmail_msg">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.<br><br></div><div class="gmail_msg">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.<br><br></div><div class="gmail_msg">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”.<br></div></div></div>