Free desktop application distribution and installation

[Alexander Larsson]

On tis, 2014-12-16 at 17:45 +0100, Mattias Andrée wrote:
> On Tue, 16 Dec 2014 11:40:29 +0100
> Alexander Larsson <alexl at redhat.com> wrote:
> 
> > There
> > is no good way for 3rd parties to distribute applications
> > (free software or not), and you can't run say a more
> > recent version of some application without being forced
> > to update to a later distro version (if the new version
> > is packaged at all).
> 
> That is a problem with the distributions. Is it not
> best if the distributions try to fix this?

Distributions are in the business of creating distributions, so I don't
see how they would be able to solve this. They are basically
self-selected to disagree with 3rd party distribution (and other
details, like bundling).

> > Long term what I want to do is full app sandboxing, but
> > that requires a lot of changes in core technologies, like
> > kdbus, DRI, wayland and pulseaudio.
> 
> Question. How does this work with all the other IPC
> mechanisms? (Signals, System V message queues, System V
> shared memory, System V semaphore sets, POSIX message
> queues, POSIX shared memory, POSIX semaphores, domain
> sockets, files)

Well, there are a lot of details here in this, but in general all of
these work, but only within the application. For instance, each
application would have its own ipc namespace (via the CLONE_NEWIPC flag
to clone) which means that it can create a system v message queue and
use it between processes inside the app. However, it can't access
message queues from the host, or other apps. 

Similar things are done for all other kernel objects. Then, starting
from a clean sheet we need to start injecting things from the host into
the app that are necessary for it to work (using various technologies
like e.g. bind mounts). After all, a desktop app that can't do any i/o
to the outside world is not very useful. However, we need to ensure that
whatever we inject is "secure" (and/or requires user agreement) when we
do this.

This is why we need some of the new technologies I mentioned before.
For instance, X11 is inherently completely insecure. Any X11 client can
access input and output from any other client on the server, without any
special permissions, and this is unfixable without breaking all apps.
With Wayland as a UI server instead things are much better, as it was
designed from the ground up to not have this kind of security problems. 
Pulseaudio is similar, anyone that manages to connect to the daemon atm
has full permissions to listen to any microphone or stream from other
apps, as well as loading modules into the server. PulseAudio needs to
add a finegrained permissions system to work for sandboxed apps. There
has been talk about a similar "PulseVideo" server for e.g. webcam
access.

Another important technology is kdbus. kdbus allows "subsetting" the bus
such that the app is "on" the bus, but can only see/interact with the
object it is allowed to, and this is enforced by the kernel. This means
dbus becomes a good place to add controlled interfaces between the app
and the host. Much of the work in creating a sandboxed app system will
be about creating such dbus APIs that allows controlled access to host
resources. (We've called these APIs "portals" in various talks on this.)

If anyone is interested in following my work on this I've been posting
to https://mail.gnome.org/archives/gnome-os-list/index.html for the last
two months talking about my research into what is required for this.