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. _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
