Re: Portals and Sandboxing

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

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.