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

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

Hi Ikey! 

Nice to read your mail. I'm glad to see you were lurking around because I was
about to mail you.

> 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 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.

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!

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).

> 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