Re: Portals and Sandboxing

[Colin Walters <walters verbum org>]

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.

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

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

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

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.

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