Portals and Sandboxing

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

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 already sent this to gnome-list but was subsequently informed it would
receive more visibility on this list, so have reposted as is.

I've recently looked into the possibility of GNOME app sandboxing and a
portal mechanism. While I've indeed come to the conclusion this is
possible, I have a few concerns about some changes that need to be made
to GNOME. Firstly lets discuss my WIP proof of concept.

An application is launched primarily inside a sandbox. My implementation
names this ISandbox, for obvious reasons. What it essentially does right
now is runs an application in a tightly controlled environment removing
write access to the rest of the system:
 * We remount "/" read-only in a bind-mount
 * We bind-mount /run to enable dbus socket access
 * We unshare the original namespace environment (CLONE_NEWNS |
CLONE_NEWPID)
 * We mount a temporary home tmpfs
 * We fork, launch the process with the calling UID via execve

The isandbox binary is setuid to root, and executes the app in a forked
process using the callers uid/gid, and does this all very quickly. The
tmpfs home option was taken merely to enable access to a temporary
XDG_CONFIG and XDG_CACHE, etc.

Also note the sandbox is currently written in pure C, without GLib2.
Reasons for this are simple, when we execute an application we retain
the option to load a different glib version, etc, in the future via a
profile concept. By linking the sandbox against glib, we lose some
flexibility by confusing the linker.

Our application currently blindly runs in a sandbox, with no notion of
being in such an environment. 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. We transfer an open (O_RDONLY) file descriptor via dbus using
GUnixFDList, enabling the client application to steal the file
descriptor. Once this is complete, the client application currently
opens the file using a GMappedFile:

        /* Obtain a file descriptor */
        portal_manager_call_get_portal_fd_sync(manager, I_PORTAL_FILES,
NULL, &fd_list, NULL, &error);
        if (fd_list == NULL || (length =
g_unix_fd_list_get_length(fd_list)) < 1) {
                printf("No files recieved!\n");
                goto end;
        }
        g_message("Got %d file descriptors", length);

        fd = g_unix_fd_list_get(fd_list, 0, NULL);
        file = g_mapped_file_new_from_fd(fd, FALSE, &error);
        if (error) {
                g_printerr("Unable to open mapped file: %s\n",
error->message);
                g_error_free(error);
                return;
        }

The idea is to wrap the dbus interface, etc, in a "portal" library. My
implementation calls them an IPortal. When I go further with this, I
envisage that only a system application may provide a IPortalProvider,
such as a libpeas plugin for cheese, accessed via I_PORTAL_CAMERA.
Returned file descriptor is an open image. Within GNOME these would take
on real names such as GPortal, G_PORTAL_CAMERA, GPortalProvider, etc.

So, we now know the application sandboxing and portal mechanism are all
entirely possible. Here are my concerns I posted online earlier on G+:

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). This should take a visual
approach, as others have done, and possibly allow the development of
GNOME Shell Extensions too.

A decision needs to be made by GNOME on the real primary development
language employed by new applications. Any distribution mechanism should
also be optimised by the client computer's app management scheme, such
as an ahead of time compiler, etc. Currently JavaScript is named as the
primary language, though it has "problems", in which case Vala is used.
Should be one or the other.

Given that JavaScript is prototyped and seemingly ill-suited to
GObject-Introspection, perhaps Vala needs re-evaluating. A logical step
might be to introduce Vala bytecode, and finish optimisation on the
target computer. This could be achieved using llvm/clang.

I believe these points need to be addressed before an app deployment and
sandboxing mechanism are even employed within GNOME.

Relevant WIP repository: https://github.com/ikeydoherty/app-concepts
Video of concept in action:
https://plus.google.com/u/0/+IkeyDoherty/posts/3LC7Mun89qm

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.