Re: Notes about GNOME OS sandboxing discussion

[Lennart Poettering <lennart poettering net>]

On Tue, 09.10.12 16:40, Stef Walter (stefw gnome org) wrote:

> At the GNOME Summit in Boston we had a discussion of the desktop use
> case for sandboxing. We steered away from technology discussion, as
> there were not many experts on that there.
> 
> The main question that we tried to answer was: What should the
> concept of GNOME OS App Store sandboxed applications look and act
> like.
> 
> Some notes of the discussion, with the hope that they're useful:
> 
> https://live.gnome.org/GnomeOS/Design/Whiteboards/Sandboxing
> 
> Please feel free to add, update and comment.

There's one thing which in the past weeks became really clear to me,
which is of major relevance to the UI, i.e. GNOME, when thinking
about sandboxing:

You already listed the privileged file chooser issue on the page. I
think this actually requires generalization.

On Android there is a framework called "intents", which allows apps to
request certain things. For example, there is an intent "get me a photo
please", in which case the camera app starts and you can take a photo
before you are returned to the original app. Or an intent for "present
the contact data of this user". These intents feel a bit like a
out GNOME mime-type thingy with meta data params, but can have a response.

Now, I strongly believe we need something similar to the intents logic,
and that's not to allow better integration between applications (which
is nice too), but simply because it clarifies the privilege crossing
between apps. Whenever an app needs access to some other resources it
fires off an intent, which then ends up being executed in a different app
context.

I am not saying that the android intents stuff is in any way directly
translatable to our stuff on Linux/GNOME, but the idea is important
because in order to open a file an app should not get free access to the
file system, if at all possible, and to take a photo an app should not
get free access to the camera, if at all possible, but the user needs to
be involved mandatorily, and that's what these intents do: they always
result in something being presented on screen, where the user explicitly
needs to do something before the operation succeeds.

So, in a way intents are a security technology. It can be used to limit
access to resources, in a similar way as PolicyKit, but the nice thing
is that the user is not even aware that he has executed a security
transition, and he doesn't need to understand this, much in contrast to
a PK-like design where everything is about passwords and explicit auth
by the user.

Intents can do much more than just being a user-friendly/controlled
security transition, they can also be used to offer multiple
implementations of the same operation, and present this to the user.

Windows8/Metro offers something similar in their "contracts" stuff.

Now, I am tempted to say that launching a file handler with the classic
mime types subsystem and selecting a file via file dialog should both just
be special cases of something like intents/contracts.

If we grok this, and want to add something like this to Linux, we need
to think what to map this to best. Quite possibly it could already be
enough to bind this dbus names, plus a few method calls, without the
need of introducing a whole new package. But yeah, we totally need to
think about this in more detail when thinking about apps and sandbox.

IIUC on windows the contracts are actually really the only way how apps
can communicate with the outside. Maybe being that drastic is not the
right approach for us on desktops, but being this strict has some appeal
to me...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.