On Fri, 2014-01-03 at 14:15 -0500, Colin Walters wrote: > On Thu, 2014-01-02 at 15:22 +0000, Michael Ikey Doherty wrote: > > > * We remount "/" read-only in a bind-mount > > [and put application files in a private directory] > > There's a lot to be discussed about application data storage. Right now > you have all sandboxed applications sharing a single store - easily > fixed, but worth noting. > > The real problem though is that we don't want to toss out unified > manageability. For example, dconf (via GSettings) allows system > administrators to lock down configuration. > > With your sandbox as it is today, the schemas won't be put in a place > where the admin can see them. (Or for that matter, running "gsettings" > from a regular user terminal won't be able to either). > > This is where large parts of the stack (dconf, gnome-keyring, etc.) need > to be aware of and integrate with the application > installation/management tooling. It can't just be a random setuid > binary. > My intent is not to concentrate just yet too much on the specifics of the sandbox itself, just general rules. The main idea now is to develop a form of communication between something "sandboxed" and system packages (i.e. GNOME and the user session) > > The isandbox binary is setuid to root, > > ...like many other projects out there such as glick2. But I don't think > this is right - applications should be launched via a (DBus) service. > Say we have systemd-for-the-session, then systemd could take care of > launching apps and setting up the environment. > > setuid binaries are a large attack surface. Indeed, and I tend to dislike them quite strongly :) I also agree that systemd also presents the best area in which to integrate such a system, especially as it is to be the kdbus driver, so to speak. isandbox is merely a demonstration, to fill in the "sandboxed app" part of the communication equation. > > > In order to access files it must talk via > > dbus to the "PortalManager". While my implementation is unfinished right > > now, this essentially is used now to open a GtkFileChooserDialog over > > dbus. > > This is the real core of the issue; how the portals are integrated with > GTK+ and the rest of the stack. > Indeed. It could be that sandboxed applications run "without modification", though this is somewhat doubtful. Whilst we could manipulate lookups for XDG directories, etc, within glib itself, data operations themselves yield the ugliest of problems. A portable communication method between sandbox app and "host" needs to be implemented, with a clearly defined mechanism for probing available resources, such as a file or camera provider, and "talking". (k)dbus seems the most logical choice, given file descriptors need to be transferred.
> > An SDK really needs to be developed. Developers need a way to target an > > existing platform version (3.10, 3.12, etc) and distribute their project > > for that version. It seems to make sense to extend from the Eclipse RCP, > > as other projects have done (i.e. ADT). > > Hah. I would certainly agree that the Eclipse ecosystem has developed a > lot of useful technology around versioning, plugins, deployment etc. > > That said, RCP is kind of a large lump to swallow for say > gnome-clocks =) > Heh, true enough. I must admit when I saw the mockup artwork for the potential GNOME IDE I somewhat drooled. Is that project still "a-go", and if so is there somewhere where I could provide a little help? > The "platform versions" have existed for quite a while implicitly in the > versions of GTK+ and GLib etc. that are used for a particular release. > But practically speaking I think we will need something a bit more > flexible than that. With my Red Hat Enterprise Linux hat on: we do a > lot of backporting, and that results in version skew. > > > A decision needs to be made by GNOME on the real primary development > > language employed by new applications. > > I disagree; applications should either be speaking to GTK+ as they do > now (directly for C/Vala apps, via gobject-introspection for bindings), > or DBus. > I guess this makes sense. Right Tool For The Job (TM) > > Relevant WIP repository: https://github.com/ikeydoherty/app-concepts > > Thanks for working on this! I think a useful milestone to target would > be sandboxing applications that need no additional permissions. For > example, gnome-calculator. > > A comparison to other projects out there (Ubuntu Click, zeroinstall, > etc.) would be useful. No worries, I wanted to get the discussion ball rolling early before kdbus is actually standard everywhere, so people have half an idea on where to start on this. Do we want something like a simple permissions system? i.e. a manifest of required permissions, closer in nature to Android apps? The alternatives are an Apple style sandbox (which I've also investigated), which has a library mechanism to sandbox your application, prohibiting all further access outside of the manifest definition from that point. This is something that could be implemented within glib itself. The other awful alternative is interactive request of permissions, ala Java Web Start.. :) Given what you've said about sandbox launching via dbus, which of course maintains a pipe of communication, perhaps library implementation would be the best course? If so, perhaps we could scratch up a basic concept of a "app", format and manifests, and actually try to build a system around the concept, rather than a concept around a non-existent system :) Kind Regards, Ikey Doherty > > > --------------------------------------------------------------------- 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
