[ANNOUNCE] xdg-app - desktop app sandboxing system

[Alexander Larsson]

xdg-app is a desktop and distribution-independent application bundling
and system for Linux. It uses user namespaces and the kernel container
technologies to run applications in a sandboxed environment without any
kind of root privileges or setuid required[1]. It also features a user
-space dbus filter with policies that are compatible with kdbus.

xdg-app is still somewhat early in development, but it is now in a
state where it is stable enough to get a wider audience.

More details on how xdg-app works can be found here:
https://wiki.gnome.org/Projects/SandboxedApps

xdg-app recently moved to a new hosting service at freedesktop.org, so
these are the current resources for xdg-app:

Mailing list: http://lists.freedesktop.org/mailman/listinfo/xdg-app
IRC: #xdg-app on freenode
Git: git://anongit.freedesktop.org/xdg-app/xdg-app
Releases: http://www.freedesktop.org/software/xdg-app/releases/
Bugzilla: https://bugs.freedesktop.org/ (product xdg-app)

To actually test xdg-app I have created upstream gnome and freedesktop
runtimes with some test apps, as well as an example repository with
runtime and apps based on fedora rawhide packages. See these blog posts
for details:
https://blogs.gnome.org/alexl/2015/03/31/official-gnome-sdk-runtime-builds-are-out/
https://blogs.gnome.org/alexl/2015/06/17/testing-rawhide-apps-using-xdg-app/

[1] Needs user namespaces in the kernel, if not available it can be
built to use setuid or setcaps instead.

[Thomas Kluyver]

Hi Alex,

Post by Alexander Larsson
https://wiki.gnome.org/Projects/SandboxedApps

Thanks, this looks interesting. A couple of questions:

How specific is a 'runtime'? If I've written an application based on
Python and Qt, for instance, do I need to define a Python+Qt runtime
based on the versions I need? Or would I use the freedesktop runtime and
specify in some other way that the application requires Python and Qt?
Or use the freedesktop runtime and bundle anything missing from it into
my application?

The wiki page mentioned distribution of apps, and I see links to
'OSTree', but I'm not quite clear what it means. What would it look like
for an application developer to package and distribute an application
like this, and what is going on when the user installs it?

On that last bit, specific examples of what I'm not sure about:
- Is it still conveyed inside an rpm/deb/whatever package, or will user
systems use OSTree to fetch it?
- Would an application developer host their own packages, or is it still
a centralised model like distro packaging? If it's centralised but
cross-distribution, who would run the repository?
- When the user installs an application, would it be like current app
installation on smartphones? "FooApp needs these permissions, OK to
install it?" Or could they deny individual capabilties? Or are the
capabilities checked by a centralised gatekeeper before the app is
available? Or some other model?

Best wishes,
Thomas

[Jasper St. Pierre]

Post by Thomas Kluyver
Hi Alex,

Post by Alexander Larsson
https://wiki.gnome.org/Projects/SandboxedApps

How specific is a 'runtime'? If I've written an application based on
Python and Qt, for instance, do I need to define a Python+Qt runtime
based on the versions I need? Or would I use the freedesktop runtime and
specify in some other way that the application requires Python and Qt?
Or use the freedesktop runtime and bundle anything missing from it into
my application?
The wiki page mentioned distribution of apps, and I see links to
'OSTree', but I'm not quite clear what it means. What would it look like
for an application developer to package and distribute an application
like this, and what is going on when the user installs it?

I can answer these bits.

Post by Thomas Kluyver
- Is it still conveyed inside an rpm/deb/whatever package, or will user
systems use OSTree to fetch it?

OSTree is a system designed for fetching and deploying system updates.
The main ostree core is composed of two things:

* a repo system, similar to git, which is more efficient for storing
binaries. This includes deltas and other such work.

* a deploy mechanism to deploy roots of a repo atomically to your
system. There's integration with bootloaders to generate configuration
files after deploys, too.

There's also an API and an ability to build on top of these systems.
So, rpm-ostree builds on top of this for its deploy stage, and we at
Endless have a different deploy system as well.

Both of these are really cool and convenient for system updates.
xdg-app is simply using OSTree for its first bit, the repo bit.
xdg-app has its own deploy stage.

Post by Thomas Kluyver
- Would an application developer host their own packages, or is it still
a centralised model like distro packaging? If it's centralised but
cross-distribution, who would run the repository?

You could run it either way. The vision here is definitely that the
app developers publish their own official builds. But Fedora might
want a central repo for all the packages in its distro.

So, I don't know, it remains to be seen. We're simply building the
tools here. Distro politics come after. :)

Post by Thomas Kluyver
- When the user installs an application, would it be like current app
installation on smartphones? "FooApp needs these permissions, OK to
install it?" Or could they deny individual capabilties? Or are the
capabilities checked by a centralised gatekeeper before the app is
available? Or some other model?

When the app is deployed, its manifest of permissions is checked to
determine what should be mounted in the sandbox. This manifest can be
edited by a user at any time. Note, however, that if the app isn't
coded for these failure cases (it was simply using a standard Linux
API), it might crash outright.

Post by Thomas Kluyver
Best wishes,
Thomas
_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

[Thomas Kluyver]

Hi Jasper,

Post by Jasper St. Pierre
Both of these are really cool and convenient for system updates.
xdg-app is simply using OSTree for its first bit, the repo bit.
xdg-app has its own deploy stage.

So it sounds like an application publisher would use OSTree to host
releases, and the user uses a custom xdg-app mechanism to fetch and
install it. This would be independent of current distro package formats.
Is that right?

Post by Jasper St. Pierre

Post by Thomas Kluyver
- Would an application developer host their own packages, or is it still
a centralised model like distro packaging? If it's centralised but
cross-distribution, who would run the repository?

You could run it either way. The vision here is definitely that the
app developers publish their own official builds. But Fedora might
want a central repo for all the packages in its distro.
So, I don't know, it remains to be seen. We're simply building the
tools here. Distro politics come after. :)

Right, but how you design the tools depends on how you expect them to be
used. I'm happy to hear that the vision is for app developers to publish
their own builds: I don't think centralised gate-keeping scales well
enough, unless you have the kind of resources Google or Apple have to
run it.

Post by Jasper St. Pierre
When the app is deployed, its manifest of permissions is checked to
determine what should be mounted in the sandbox. This manifest can be
edited by a user at any time. Note, however, that if the app isn't
coded for these failure cases (it was simply using a standard Linux
API), it might crash outright.

I'm still a bit unclear on what the trust model is - would the user be
clearly shown the permissions manifest in an understandable format
before they use the application, so they could see if it was trying to
do anything sneaky? Or is the idea that you trust the app author, and
permissions are a way to limit the impact on the system if there's a
security bug in that app?

Again, it's the vision I'm interested in - I understand that it's early
days for the project and this kind of user-visible stuff might be some
way off. But it's good to know what it's driving towards.

Thanks,
Thomas

[Alexander Larsson]

Post by Thomas Kluyver
Hi Jasper,

Post by Jasper St. Pierre
Both of these are really cool and convenient for system updates.
xdg-app is simply using OSTree for its first bit, the repo bit.
xdg-app has its own deploy stage.

So it sounds like an application publisher would use OSTree to host
releases, and the user uses a custom xdg-app mechanism to fetch and
install it. This would be independent of current distro package formats.
Is that right?

The easiest explanation is to just look at an ostree repo. Take this
one of some example apps for instance:

https://people.gnome.org/~alexl/test-apps/repo/

To use this you do:

$ xdg-app add-remote --no-gpg-verify test-apps https://people.gnome.org/~alexl/test-apps/repo/
$ xdg-app install-app test-apps org.gnome.gedit

Post by Thomas Kluyver

Post by Jasper St. Pierre
When the app is deployed, its manifest of permissions is checked to
determine what should be mounted in the sandbox. This manifest can be
edited by a user at any time. Note, however, that if the app isn't
coded for these failure cases (it was simply using a standard Linux
API), it might crash outright.

I'm still a bit unclear on what the trust model is - would the user be
clearly shown the permissions manifest in an understandable format
before they use the application, so they could see if it was trying to
do anything sneaky? Or is the idea that you trust the app author, and
permissions are a way to limit the impact on the system if there's a
security bug in that app?
Again, it's the vision I'm interested in - I understand that it's early
days for the project and this kind of user-visible stuff might be some
way off. But it's good to know what it's driving towards.

Right now the format is really a developer thing. But, exposing it in
an easy to understand way (and to allow overriding it) is the long term
goal.

[Alexander Larsson]

Post by Thomas Kluyver
Hi Alex,

Post by Alexander Larsson
https://wiki.gnome.org/Projects/SandboxedApps

How specific is a 'runtime'? If I've written an application based on
Python and Qt, for instance, do I need to define a Python+Qt runtime
based on the versions I need? Or would I use the freedesktop runtime
and
specify in some other way that the application requires Python and
Qt?
Or use the freedesktop runtime and bundle anything missing from it
into
my application?

A runtime is very specific. It defines an exact ABI and is then
supposed to continue to support exactly that ABI. If anything that you
need is not shipped in the runtime you chose to use, you need to bundle
those with the app. In general you should not define your own runtime,
doing that is analogous to creating (and supporting) your own distro.

Post by Thomas Kluyver
The wiki page mentioned distribution of apps, and I see links to
'OSTree', but I'm not quite clear what it means. What would it look
like
for an application developer to package and distribute an application
like this, and what is going on when the user installs it?

The best way to describe ostree is that it is "git for operating system
trees". You have a repository with several branches, and you can pull
and push and commit, etc. Typical distribution is via a "dumb http"
version of the ostree repo. I.e. you just create your repo (via xdg-app
build-export) and put the resulting files on your webserver.

When downloading it for the user the ostree parts are hidden, you just
do:
xdg-app add-remote repo-name http://url.to.repo.org/repo/
xdg-app install-app repo-name org.app.name

Post by Thomas Kluyver
- Is it still conveyed inside an rpm/deb/whatever package, or will
user
systems use OSTree to fetch it?

ostree is used under the hood. But rpm/deb/whatever can be used to
construct the app on the developer side.

Post by Thomas Kluyver
- Would an application developer host their own packages, or is it
still
a centralised model like distro packaging? If it's centralised but
cross-distribution, who would run the repository?

Generally it is distributed. Each upstream hosts their own repo.
However, a distro can chose to build and host other peoples apps in a
repo they want. And I want to also allow centralized app repositories
that contain links to the upstream repostories, so that you can manage
an "app store" by just collecting upstreams, making sure the apps are
working and do what they say and then signing the links with your own
gpg key.

Post by Thomas Kluyver
- When the user installs an application, would it be like current app
installation on smartphones? "FooApp needs these permissions, OK to
install it?" Or could they deny individual capabilties? Or are the
capabilities checked by a centralised gatekeeper before the app is
available? Or some other model?

Right now an app just gets whatever they ask for. At some higher level
we should probably ask the user during install if this ok.

[Thomas Kluyver]

Thanks Alex,

Post by Alexander Larsson
A runtime is very specific. It defines an exact ABI and is then
supposed to continue to support exactly that ABI. If anything that you
need is not shipped in the runtime you chose to use, you need to bundle
those with the app. In general you should not define your own runtime,
doing that is analogous to creating (and supporting) your own distro.

Just to check, though, a user can have more than one runtime available
on their system, right? I hope the distro doesn't decide on a single
runtime that all apps must use.

Post by Alexander Larsson
ostree is used under the hood. But rpm/deb/whatever can be used to
construct the app on the developer side.

But there's one package which users of all distros can install, correct?
i.e. The app developer doesn't need to make an rpm package *and* a deb
package and so on.

Best wishes,
Thomas

[Alexander Larsson]

Post by Thomas Kluyver
Thanks Alex,

Post by Alexander Larsson
A runtime is very specific. It defines an exact ABI and is then
supposed to continue to support exactly that ABI. If anything that you
need is not shipped in the runtime you chose to use, you need to bundle
those with the app. In general you should not define your own runtime,
doing that is analogous to creating (and supporting) your own distro.

Just to check, though, a user can have more than one runtime
available
on their system, right? I hope the distro doesn't decide on a single
runtime that all apps must use.

Sure, multiple versions of multiple runtimes all installed in parallel.

Post by Thomas Kluyver

Post by Alexander Larsson
ostree is used under the hood. But rpm/deb/whatever can be used to
construct the app on the developer side.

But there's one package which users of all distros can install, correct?
i.e. The app developer doesn't need to make an rpm package *and* a deb
package and so on.

Once you made an app of it you don't have to care that the developer
used rpms to create the app. Its just a bunch of files in an ostree
repo.