Fedora runtimes and sandboxed desktop applications

Thu May 28 01:55:08 UTC 2015

Is this related to the proposal to build a "desktop" via Project
Atomic? That seems to me a much simpler approach.

TBH, my "ideal desktop" would look like a ChromeBook except

1. Project Atomic as the OS, serving up web apps in containers, and
2. Firefox Developer Edition as the browser.

On Wed, May 27, 2015 at 2:50 AM, Alexander Larsson <alexl at redhat.com> wrote:
> I'm working on an application sandboxing system called xdg-app, and
> the surrounding echo-system. I won't go into details, but there are
> some links to technical details at the end of the mail[1]. The basic
> idea is that we have two sources (both ostree trees), one called the
> runtime (/usr), and one called the app (/app), which get combined in a
> container-like environment at launch time by xdg-app, with configurable
> degrees of sandboxing. There is also some interaction with the host
> system so that installed desktop files show up in the shell and dbus
> session services from apps work.
>
> xdg-app has two major goals, the first is to allow applications to run
> in a sandboxed environment with minimal access to the host. The second
> is to allow third parties to create and distribute applications that
> run on all distributions (and the sandboxing helps making this less
> risky). To facilitate and test this I've also created an upstream
> gnome runtime[2] that gnome applications can chose to use. I'm also
> working on various Portal APIs[3] that allow sandboxed applications to
> safely interact with the system.
>
> But, third party applications are a long way off in the future, and so
> are sandboxed applications (which need not only a fleshed out set of
> sandbox APIs, but also modifications to individual apps). In the
> meantime it is still interesting to run bundled applications. For
> instance in the context of an Atomic-based Fedora Workstation (with
> readonly /usr), or if you want to run older or newer versions of
> applications than your distribution is shipping.
>
> It would make a lot of sense to use the existing packages in Fedora
> for this. And in order to kickstart discussions about this I've
> created an initial sample of a possible Fedora runtime using
> rpm-ostree and the Fedora 22 repositories:
>
>   https://github.com/alexlarsson/fedora-runtime
>
> Building this produces a repo with the main runtime
> (org.fedoraproject.Platform) and a sdk runtime (org.fedoraproject.Sdk)
> which has some additional tools for app creation and debugging. It
> also builds .Var subruntimes that contain /var with the rpm db
> for use when building apps. The current package set is mostly based on
> what is in the gnome one, so don't consider this official in any way.
>
> These runtimes are made to work with xdg-app 0.3.0 which are now in
> updates-testing for F21 and F22. You also need rpm-ostree from git
> master for the container support to build the fedra runtime.
>
> In order to test the runtime I've also created a firefox application
> bundle. Unfortunately it requires some hacks in order to be relocated
> to /app, and to work as a bundle. However, it works pretty well,
> running somewhat contained with only access to the Downloads xdg
> directory and with ~/.mozilla being redirected to the per-app
> persistant data directory (~/.var/app/org.fedoraproject.firefox). Note
> however, that I would not consider this properly sandboxed, as it uses
> X11 for rendering, which is not very secure.
>
> The scripts to build the firefox bundle is here:
>
>    https://github.com/alexlarsson/fedora-apps
>
> I've also put up a xdg-app repository so that you can easily test this:
> (Run these commands as non-root, due to the --user args)
>
>   xdg-app add-remote --user --no-gpg-verify fedora http://people.redhat.com/~alexl/repo
>   xdg-app install-runtime --user fedora org.fedoraproject.Platform 22
>   xdg-app install-app --user fedora org.fedoraproject.firefox
>   xdg-app run org.fedoraproject.firefox
>
> Once installed the desktop file will be exported to the session, so
> you should also be able to launch it from the shell. In theory this
> should work on any distro, but I've only tried it on F21.
>
> The question is, would the Fedora project be interested in supplying
> and maintaining a Fedora runtime like this, which allows us (and
> others) to create applications using the fedora base. And if we do,
> exactly what should be considered part of the basic platform.
>
> Defining a platform requires a lot of care. It is a balance between
> wanting as much as possible in it to share more maintainance and
> updates and make it easier to write apps and on the other hand trying
> to keep the basic platfrom small, maintained and of high quality. The
> ABI requirements for a platform is a bit different than a regular
> distro. The goal is to allow apps built against a particular platform
> to run for years to come, so it should only do security and very
> important bugfix updates, and *never* break ABI. On the other hand,
> its easy to break ABI in a later version of the runtime, because they
> are parallel installed. This is somewhat different than our current
> updates which revs libraries during the distro lifetime as long as it
> also updates all users of it.
>
> An added complexity is that anything in the runtime that relies on
> some kind of IPC to the host (say the pulseaudio client libraries, or
> something that uses a dbus interface on the host) requires the host
> side of that IPC to remain available and backwards compatible in
> future versions of the distro, so we should err on exposing a minimal
> set of IPC.
>
> There is also some changes that may be required in the distro to keep
> unnecessary dependencies out of the runtime. For instance anything
> related to hardware or system initialization is completely
> unnecessary. Luckily much of this is being fixed by similar needs from
> docker already.
>
> One thing that is different from docker however, is that we generally
> want translations/locales in the runtime. But these are pretty large,
> so we want to handle them in a smart way. xdg-app has a feature that
> allows splitting a runtime into a base and a set of optional
> extensions that are mounted in the sandbox only when they are
> installed. I use this in the gnome runtime to split out each
> locale. Unfortunately Fedora uses a single large locale-archive file
> for its locales, so its hard to do that. This needs some research to
> figure out how to do properly.
>
> There are also some custom configuration that a runtime needs. For
> instance, the build script for the fedora runtime above drops in a new
> fontconfig file that adds a /app/share/fonts fontdir for app-bundled
> fonts and configuration to include the host fonts (which xdg-app
> exposes in /run/host/fonts). This would be nicer if this was just a
> fontconfig subpackage we could pull in, and I'm sure there are more
> similar configuration options that would be needed.
>
> Creating applications from fedora packages is a bit more
> complicated. The primary reason is that they need to be relocated to
> /app. In the hacky script above I just extract the rpm contents to
> /app and then rewrite some rpaths and shell scripts. A less hacky
> approach is to rebuild the rpms with a different rpm %_prefix macro,
> or to use relocatable rpms. It is not really significantly different
> from creating rpms to use in software collections though, so we have
> some experience with this.
>
> Packaging an application also requires some changes other than the
> relocatability itself. First of all, all "exported" files from an
> application (such as icons, desktop files, dbus service files, or
> other files that are read from outside the app itself) must have the
> application id (which is a dbus/java-style reverse dns name) as a
> filename prefix. This is both for avoiding conflicts, and for security
> reasons, see [4]. However, it wouldn't necessarily be a problem if we
> just did such changes on the regular fedora packages too, as a regular
> fedora packaging policy.
>
> One issue is that as third party packagers of applications we should
> not use the "official" app ids for our builds, as they would conflict
> with upstream doing their own release. So, our package of
> org.gnome.gedit should probably be called org.fedoraproject.gedit,
> which may require some minor tweaks to the build (for instance, this
> affects the dbus name the app uses for dbus activated desktop files,
> as well as the name of the desktop file itself).
>
> There are clearly a lot of details here, but I'll stop here and throw
> this out as the start of a discussion. I'll gladly reply to any
> questions people may have.
>
>
> [1] More information:
>    My devconf talk: https://www.youtube.com/watch?v=t-2a_XYJPEY
>    gnome wiki: https://wiki.gnome.org/Projects/SandboxedApps
>    xdg-app code: https://github.com/alexlarsson/xdg-app
>
> [2] Announcement of gnome runtime:
> https://blogs.gnome.org/alexl/2015/03/31/official-gnome-sdk-runtime-builds-are-out/
>
> [3] https://wiki.gnome.org/Projects/SandboxedApps/DocumentPortal
>     https://wiki.gnome.org/Projects/SandboxedApps/Sandbox
>
> [4]
> https://mail.gnome.org/archives/gnome-os-list/2015-February/msg00009.html
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  Alexander Larsson                                            Red Hat, Inc
>        alexl at redhat.com            alexander.larsson at gmail.com
> He's a war-weary Republican vampire hunter on a search for his missing
> sister. She's a ditzy winged queen of the dead with the power to see
> death. They fight crime!
>
> --
> desktop mailing list
> desktop at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/desktop

-- 
OSJourno: Robust Power Tools for Digital Journalists
http://www.znmeb.mobi/stories/osjourno-robust-power-tools-for-digital-journalists

Remember, if you're traveling to Bactria, Hump Day is Tuesday and Thursday.