Re: Portals and Sandboxing

[Alexander Larsson <alexl redhat com>]

On tor, 2014-01-02 at 15:22 +0000, Michael Ikey Doherty wrote:
> Hello,
>
> My name is Michael Ikey Doherty, though some of you will know me as Ikey
> Doherty. A quick introduction: I'm a software engineer at Intel and have
> worked with the GNOME stack for a few years. I've mostly been known for
> distribution development, </endintro>

I'm guessing you're aware of the linux apps project:
https://docs.google.com/document/d/1QTgxakyUVFMkvr-xFY2Xg9lYjcJLd6kPTl3Ij5_dL7Q/edit

As part of that we've talked quite a bit about "portals". Essentially,
the idea is that by default, a sandboxed applications gets its own kdbus
sub-session-bus, which is forbidden to talk to any other peer on the
session bus (this can be opened up by fine grained permissions of
course). Except there would be one service that you're allowed to talk
to, the Portal. 

The portal is a meant to be a pretty minimal dbus API that essentially
acts as a form of proxy to other services on the bus, in much the same
fashion of how well known dbus names act as a proxy. For example, on the
normal dbus you can message a well know name org.gnome.Foobar and assume
that it will implement a known interface for Foobars (as defined by some
external entity). You don't have to know who implements the foobar, and
if its not running it will be activated.

In the same way you can send requests to the portal manager targeting a
named portal. The portal manager will activate the right target and send
the message there, and the target will have to implement the defined
interface for that particular portal name.

The main difference is that portal interfaces are limited in certain
ways to make them "safe" for any app to use. First of all, all the
operations are meant to be interactive, i.e. they never return any data
to the app unless the user did something, and the user is always able to
cancel the operation. And I don't mean a "the app wants to do foo, allow
yes/no" dialog, but an actual interactive operation.

Let me give some example portals:

Share portal: The user selects some text or image in an app and clicks
the "share" button, which triggers a share portal call. This will
typically show a list of possible ways to share things, or if there is
only one way it will be launched. But the launched thing is meant to be
e.g. a twitter compose dialog with the text inserted ready to be
tweeted, rather than something that just immediately tweets the text.
This way an app can't misuse this to e.g. tweet as you without you
knowing it. In this way every portal action is interactive, cancellable
and will feel natural when invoked by the user (but weird when the app
does so unexpectedly).

Get an image portal: Allows you to insert an image into an app. When you
activate this you get a dialog that allows you to select an image via
e.g. picking a file or using a webcam.

Select a file: Opens up a file selector, and if a file is selected
streams the contents to the app so that it can read it even if it has
no access to $home otherwise.

Select a contact: Contact chooser UI that lets you chose from your
addressbook and return (only) the selected result to the app, without
the app having access to the addressbook.

The portal manager by itself is not terribly complex, but defining all
the dbus interfaces for possible portals (and adding gnome
implementations for some standard ones) is a lot of work. However, this
is work that can be done incrementally. All you need is to define a well
known portal name and some dbus introspection xml describing the
interface. Then any app can use the introspection xml either at runtime,
or at compile time using gdbus-codegen to create nice GObject wrappers
for it.

The disucssion about portals and the linux apps project is kind of
dormant atm as the interested parties are busy with other stuff. But
things are progressing at some fronts at least, like the kdbus work
which will be great for this.