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

[Michael Ikey Doherty <michael i doherty intel com>]

On Wed, 2014-04-02 at 03:42 +0000, Dodier-Lazaro, Steve wrote:
> Hi Ikey! 
>
> Nice to read your mail. I'm glad to see you were lurking around because I was
> about to mail you.
Well, looking at the mail subject and given I'd discussed it not too
long ago, I figured my name would crop up at some stage :)
> > Well, you're probably right there. I was thinking more of catch-all
> > cases.. but we should be maintaining a consistent usage of API. Having
> > it happen transparently through existing systems makes most sense, i.e.
> > via GtkFileChooser, GApplication, etc. (Modified launch context wouldn't
> > hurt either)
>
> In the long run breaking API in a symbolic way may be salutary, because we need
> to check which apps do get ported and behave nicely because their developers play
> by the rules and which play nicely by accident because somebody hacked some
> retrocompatibility! Though keeping very close to the current API (or mapping to it)
> means super easy maintenance for app devs :)
I'm going to be very blunt here: API changes make GNOME very unpopular.
Avoid.
> I'm not sure what's gonna happen in the future, but both FDs and filenames leak
> some information about the OS configuration -- which could be used by malware devs
> in a way or another if they find exploits? (e.g., you find out a names of folders,
> or what other open FDs are possibly open). This begs the question of which is
> better to leak and maybe that should be a criteria for choosing which final API is
> the best.
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.
> Likewise, do FDs and filenames have a utility for app developers? In which contexts
> and what can be done about it? Is the information leak of a filename worthy of the
> benefits to app devs? That's tiny details but still interesting to look at!
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.
> Thanks for pointing out to GApplication. That class has interesting stuff with
> security implications indeed. I also would like to get rid of g_set_prgname()
> and debate the meaning and practice of gtk_window_set_title for an app's root
> window (allegedly that could contain a unique id for the app, set by the OS,
> because I don't want an app to cheat about its identity and mimic another app).
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. 
> > 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!
>
> 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

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.

- Ikey

---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.