Last week I had the chance to attend for 3 days the GNOME Software Hackfest, organized by Richard Hughes and hosted at the brand new Red Hat’s London office.
And besides meeting new people and some old friends (which I admit to be one of my favourite aspects about attending these kind of events), and discovering what it’s now my new favourite place for fast-food near London bridge, I happened to learn quite a few new things while working on my particular personal quest: getting Chromium browser to run as an xdg-app.
While this might not seem to be an immediate need for Endless right now (we currently ship a Chromium-based browser as part of our OSTree based system), this was definitely something worth exploring as we are now implementing the next version of our App Center (which will be based on GNOME Software and xdg-app). Chromium updates very frequently with fixes and new features, and so being able to update it separately and more quickly than the OS is very valuable.
Screenshot of Endless OS’s current App Center
So, while Joaquim and Rob were working on the GNOME Software related bits and discussing aspects related to Continuous Integration with the rest of the crowd, I spent some time learning about xdg-app and trying to get Chromium to build that way which, unsurprisingly, was not an easy task.
Fortunately, the base documentation about xdg-app together with Alex Larsson’s blog post series about this topic (which I wholeheartedly recommend reading) and some experimentation from my side was enough to get started with the whole thing, and I was quickly on my way to fixing build issues, adding missing deps and the like.
Note that my goal at this time was not to get a fully featured Chromium browser running, but to get something running based on the version that we use use in Endless (Chromium 48.0.2564.82), with a couple of things disabled for now (e.g. chromium’s own sandbox, udev integration…) and putting, of course, some holes in the xdg-app configuration so that Chromium can access the system’s parts that are needed for it to function (e.g. network, X11, shared memory, pulseaudio…).
Of course, the long term goal is to close as many of those holes as possible using Portals instead, as well as not giving up on Chromium’s own sandbox right away (some work will be needed here, since `setuid` binaries are a no-go in xdg-app’s world), but for the time being I’m pretty satisfied (and kind of surprised, even) that I managed to get the whole beast built and running after 4 days of work since I started :-).
But, as Alberto usually says… “screencast or it didn’t happen!”, so I recorded a video yesterday to properly share my excitement with the world. Here you have it:
[VIDEO: Chromium Browser running as an xdg-app]
As mentioned above, this is work-in-progress stuff, so please hold your horses and manage your expectations wisely. It’s not quite there yet in terms of what I’d like to see, but definitely a step forward in the right direction, and something I hope will be useful not only for us, but for the entire Linux community as a whole. Should you were curious about the current status of the whole thing, feel free to check the relevant files at its git repository here.
Last, I would like to finish this blog post saying thanks specially to Richard Hughes for organizing this event, as well as the GNOME Foundation and Red Hat for their support in the development of GNOME Software and xdg-app. Finally, I’d also like to thank my employer Endless for supporting me to attend this hackfest. It’s been a terrific week indeed… thank you all!
Credit to Georges Stavracas
The xdg-app idea is new to me, so please forgive me if my question is stupid. Following your link to xdg-app, an important goal seems that “it allow you to trust the applications less, which is important for users of 3rd party applications”. So what is point of distributing a web browser as a xdg-app? There are not many programs, I need to trust more than my web browser, right? For me, having a trusted web browser directly from my trusted distribution seems to be essential. Why would one want to trust a 3rd party? TIA!
For example official Firefox builds are built with profile-guided optimizations and some other stuff while most distributions do a ‘regular’ build. As a result Firefox from Mozilla is faster (reportedly even 30% for some tests) than distro builds.
And restricting the permissions of apps means that e.g. even if attacker takes control of your browser, he will have a harder time taking control of your PC.
It’s not a stupid question at all. Actually I’m myself still in the process of learning about xdg-app, so I might very well not have the whole full picture yet either, but still I’ll try to answer below…
First of all, as Imię mentioned, xdg-app is not only about “allowing you to trust the applications less” in that way you put it, but about making it harder for them to take control of your system, should an attack happened, which is pretty much one of the reasonings (besides with stability and performance) behind the multi-process and sandboxed architecture of Chromium itself. So, from that point of view, being able to run the browser as an xdg-app would actually improve things in my opinion (and the bundle could come from your trusted distribution, too).
But besides those benefits, being able to ship Chromium as a bundle has other ones: In our particular case, we could decouple the OS upgrades from the browser’s updates, which would be indeed quite a big thing, so that Endless users would still receive those updates from their trusted “distribution” (EOS is not really a distro, but still) without waiting for the next OSTree upgrade.
Then, in a more general case, this could open the door for the distribution of Chromium (and even Chrome, if Google wants) uniformly across Linux distros as an xdg-app, as well as be particularly handy for cases with strict policies when it comes to distributing sofware with bundle-in libraries (e.g. Fedora), so that they have an alternative way to deal with those situations.
And I’m sure I’m forgetting to mention other things… :-)
Maybe I’m too conservative for such things, but I’m not so worried that my web browser “takes control of my PC”. I’m much more worried whether my web browser could send information related to one web site to another, e.g. bank account details to a black hat.
Also, while running an application in an isolated container is a good idea, but could be handled within the existing distributions, with any DEB or RPM package. When I’m running Debian or Fedora or whatever, I already decided to fully (not to say blindly) trust “my” distribution. I don’t believe that extending this trust to additional parties improves security. Some people might trust Debian or Fedora more than Google or Mozilla Inc, but YMMV :~)
The policies Fedora, Debian and other distributions have in respect to bundling, are very good and useful, because security fixes in a library have to fixed only once. If I understand correctly, xdg-app would be a way to circumvent such security measure, and I would have to update all applications that have the vulnerable library bundled, right?
I agree with your concerns, but I fail to see why they are incompatible with chromium running as an xdg-app.
After all, the fact that it’s possible to distribute the browser as a bundle does not mean that you have to install it from any untrusted source out there: you could install it from any third party that provides it, true, but also from your trusted distribution if it offers that possibility, in which case there would really not be much of a difference compared to what you already do now, right?
About the problem with bundled libraries that you mention, needing to update all bundled apps depending on a buggy library to get it fixed is indeed an issue, but only for those libraries that are not contained in the runtime, which gets updated independently of the xdg-app itself. But in any case, this is IMHO yet another reason to keep distributing core components as it’s been done so far, and leave this model only for apps (which should ideally be properly sandboxed, to contain any potential harm they could cause).
Now, for the particular case of chromium… it’s not that the difference is going to be huge precisely, since chromium already bundles a lot of libraries anyway. Actually, the only libraries I needed to add so far to build it where lspci and alsa-lib, everything else was already being provided by the xdg-app runtimes, so not that a big deal as it might look at a first glance. It’s basically almost the same thing, with a different packaging :-)
Are you sure about chromium bundling libraries? I count almost fourty depencies in my chromium packages, such as libasound, libcairo, libcups, libdbus, libglib/libgtk, libnspr, libx*…
Also, I’m not sure, whether I would like the idea in splitting a distribution into “core” and “apps”. It sounds like an arbitrary distinction. And what about dependencies between packages?
Maybe I’m a little bit scared when I see the word “apps”. It reminds me of my telephone, which unfortunately does not have proper package management, but only “apps”.
Most of the libraries you mentioned come with the xdg-app runtime, so there’s no need to bundle them together with chromium. When I said that I only needed to add alsa-lib and lspci for now I meant “inside the app bundle”, but of course chromium requires all what you mentioned too. It’s just that I don’t have to worry about it from the application’s point of view.