RE: Request for comments on security of authentication/authorisation UIs

["Dodier-Lazaro, Steve" <s dodier-lazaro 12 ucl ac uk>]

Hi,

Re-shaping the mail a bit, first about API compat and then other details.

> I'm going to be very blunt here: API changes make GNOME very unpopular.
> Avoid.

> Why g_str_prgname() ? It's useful for debugging applications. It has no
> security implications. And while I understand your concern for setting a
> title on a GtkWindow, I find your enthusiasm for breaking existing API
> disturbing. The only instance in which an application is run on Linux
> systems comes from a user downloading, and running (Usually installed
> via a package manager). Even if an application is marauding as something
> else - its already limited by the rest of the architecture in what it
> can do. 


I'd like to make points that there will be new API stuff if Sharing and Portals do
get implemented, and it's likely that apps get full benefits of the changes only if
they port to new APIs. For instance, the password keyring popover may need the use
of a shiny new widget - also some new widgets that allow access to specific bulks
of data might be developed -- whilst in contrast file dialogs, recent files menus
and print dialogs can be transparently secured. That's point 1.

Of course we can do a look of stuff just with hooking to existing GTK functions
and then deny-default'ing when what the app does is contrary to the security
policy. Then we can hope for the best in terms of error handling and reporting to
the end user. In summary, point 2: we're not explicit about the error management
introduced by the absence of previously available resources with sandboxing.

Point 3 relates to the fact that some API may indeed change for maximum 
security. If you want to return FDs for file or for screenshot access you will
need API changes and you will need apps to adjust to those changes. Otherwise you
need to transparently make resources available as they used to be, whenever your
hooks suggest an app rightfully needs a resource.


Now this is all conditional on us and others finding that there are things that
are worth getting done and that does not mean that app developers will get new
APIs stuffed down their throats out of the blue, in a "comply or die" fashion!

Some of this will probably organically need to occur with Wayland, because I do
think that locking down access to APIs like clipboards, virtual input devices, etc.
will change the way some code is written. It may be only a concern for toolkit
developers but I suspect there may be side-effects that app developers will need
to be aware of. It'd also be nice if GTK and Qt don't start coding their own internal
clipboards just to defeat the security logic that an app should not be able to rip
off all that is typed in your clipboard or selected with your mouse without you
knowing. I hardly find an excuse for such permissive APIs and that does not reflect
users' expectations, imo.

Now with some more optimistic stuff: most of the changes that could do some good
to security and make sandboxing tractable on a large enough scale do not need to
happen overnight. I'd say, let's write up some new shiny APIs that are easy to
use, provide some benefits to developers AND a contain security logic as opposed
to existing modes of accessing the keyring, files and various devices. Let people
adopt them, incencitise them by marking the "old" APIs as deprecated (but let them
stick around of course). And then in a few years' time when every distributor is
ready to ship Wayland-enabled desktop environments and DEs provide ways for users
to automatically or "one-click-ally" sandbox their apps, we'll see how many of
them ported to the new APIs, how many work out of the box (or rather inside the 
box ;)) with legacy API support and how many do non-standard/insecure stuff.

The point of flagging a class as deprecated and providing the exact same features
in another class is more a matter of getting some overview on how willing app
developers are to help you secure Linux. I think it could be discussed before being
discarded :)

In short: I don't feel a compulsive need to destroy APIs but I think a thorough
discussion of whether keeping the current API in ten years is the right thing to
do -- or whether smooth transitions can occur without causing another FOSS
rioting campaign -- could occur.
 
 
> A process can only access its own file descriptors unless explicitly
> shared by a socket. Hence isandbox's demonstration. If the sandbox is
> implemented correctly within systemd, and utilising kdbus, you already
> have systemd and an LSM in place to keep things safe.
> You also need to write to a file after reading it. Text editors need to
> display the file name (It can be a relative filename, but good UIs will
> inform the user of the file they have open) - Sockets also need file
> descriptors - but this is a different discussion.

My point was more about whether some classes of vulns would be facilitated if a
malware app (inside a sandbox) came to be able to predict filenames/FDs for other
files than those already acquired. Kind of not an important detail to discuss
though. Indeed my view is that full file paths are very useful to have!


> > > Point me in the rough general direction when you've got a bit of an idea
> > > on how it wants to be implemented, and I'll turn it into codes (TM) (An
> > > idea doing the rounds is implementing the helper within systemd,
> > > ensuring a sane init daemon is present in this sandbox, enabling proper
> > > kdbus, security, launching of the the process itself, and ensuring the
> > > use of pivot_root and bind-mounts)
> >
> > Well, as much as I like help I really need to take some time to write code myself
> > because I rust entirely :) I'll do the GTK Dialog running transparently through DBus
> > (hopefully within next week), though I'll shamelessly reuse your isandbox for 
> > demonstration purposes. I had some silly issues trying to spawn my own provider
> > through systemd (ending up with its own DBus daemon, obviously there's something
> > cheesy about the doc I used to implement that!). If you feel that that one needs
> > some updating or that we could already make a watchdog-using systemd provider for
> > demo purposes, we can do that together!
>
> No problem. The demonstration is there merely as a PoC. isandbox should
> not be employed as the default mechanism, as its a setuid binary with no
> real tests or error handling (Well, it does, but its not intelligent).
> It's there to get people thinking and hopefully to come to a solution.

Alright. I'll use your box for my PoC. I don't have so much knowledge about systemd,
Docker, namespaces, etc. and I'm not capable (yet!) to distinguish what the best
approach to sandboxing is. It seems to me Lennart is slowly putting things together
and has a secret plan in mind... Can you guys please keep me in touch with what
happens at the GNOME hackfest in two weeks?

Thanks,
--
Steve Dodier-Lazaro
PhD student in Information Security
University College London
Dept. of Computer Science
Malet Place Engineering, 6.07
Gower Street, London WC1E 6BT
OpenPGP : 1B6B1670