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