Flatpak 1.0 released

[Posted August 20, 2018 by corbet]

The 1.0 release of the Flatpak application distribution system is out. There are a number of performance improvements, the ability to mark applications as being at end-of-life, up-front confirmation of requested permissions, and more. "Apps can now request access the host SSH agent to securely access remote servers or Git repositories."

Application isolation

Posted Aug 21, 2018 12:09 UTC (Tue) by astian (guest, #118981) [Link] (15 responses)

I remember during the early hype days of Flatpack and containers, the former was hailed as a secure(r) mechanism for 'running arbitrary blobs off the Internet' (windows style), because each Flatpack-packaged application was supposed to run confined into a container which was largely isolated from the rest of the system. Later when Canonical released (or announced, can't remember) Snappy, the people behind Flatpack rushed to a sort of 'preliminary' release. In order to make the deadline, several features had to be scrapped^Wpostponed, one of them being isolation, the only one I was really interested in.

I wonder if/how the situation has changed.

Application isolation

Posted Aug 21, 2018 14:48 UTC (Tue) by tux3 (subscriber, #101245) [Link] (5 responses)

My understanding is that they've been using Bubblewrap as a sandbox (https://github.com/projectatomic/bubblewrap), which is a sort of homemade lightweight user namespaces implemented with a setuid helper.

As far as I can tell, as of today their sandbox seems perfectly functional, but if there's some fine print hidden somewhere I'd love to take a look at it!

Here's their wiki that I've only quickly glossed over: https://github.com/flatpak/flatpak/wiki/Sandbox

Application isolation

Posted Aug 21, 2018 22:43 UTC (Tue) by smcv (subscriber, #53363) [Link] (4 responses)

The sandbox itself is as good as any other unprivileged container based on namespaces: the sandboxed app has access to the kernel's (significant) attack surface, but with strict permissions it can't do much to interact with the rest of the system. On some kernel configurations (notably Debian and RHEL), bubblewrap normally needs to be setuid; on others (notably Fedora and Ubuntu), it can be unprivileged. (The difference is because by default Debian and RHEL kernels don't let unprivileged users create their own user namespaces, whereas Fedora and Ubuntu kernels do.)

The fine print is that to let an app do useful things (draw a window, play sounds, contact network services, load and save per-user preferences, etc.) it needs to have some permissions (gaps in the sandbox boundary), and at the moment many of those permissions are more coarse-grained than you might hope: for example, access to PulseAudio is currently a binary yes/no choice per app, and there's no way to say "this app can play sounds, but can't use PulseAudio's shared-memory transport, and can't record". This should get better with continued development, partly in Flatpak itself and partly in other projects adjacent to it.

Application isolation - PA

Posted Aug 22, 2018 10:05 UTC (Wed) by darwish (guest, #102479) [Link] (2 responses)

> for example, access to PulseAudio is currently a binary yes/no choice per app, and there's no way to say "this app can play sounds, but can't use PulseAudio's shared-memory transport, and can't record".

This was initially going to be solved by adding Access Control support to PulseAudio, along with lots of PA code re-design to guarantee real isolation:

https://www.freedesktop.org/wiki/Software/PulseAudio/Docu...

https://lists.freedesktop.org/archives/pulseaudio-discuss...

AFAIK Fedora merged these Access Control patches on their own, but as seen above they are definitely not enough. The tide now is go with PipeWire since it's careful to solve this problem correctly from the start.

Application isolation - PA

Posted Aug 22, 2018 14:02 UTC (Wed) by kloczek (guest, #6391) [Link] (1 responses)

So many years people have been telling to stop doing those nasty things with alsa/pulseaudio in user space and move all to kernel space .. no one listens.

Application isolation - PA

Posted Aug 22, 2018 17:41 UTC (Wed) by zlynx (guest, #2285) [Link]

How exactly would that help? If the kernel audio interfaces allowed recording you'd be in the same fix because the kernel ABI cannot be changed.

In the past before ALSA with OSS audio there were horrible library hacks to intercept open(), read(), write(), ioctl() calls to audio devices so that kernel behavior could be modified. There are *reasons* why things are now in userspace.

Application isolation

Posted Aug 22, 2018 19:57 UTC (Wed) by astian (guest, #118981) [Link]

Thanks for the summary.

Application isolation

Posted Aug 21, 2018 16:11 UTC (Tue) by drag (guest, #31333) [Link]

I think your memory isn't very good. Seems your recollection of events is little more then a series of strawmen and half remembered assumptions.

Regardless getting applications sandboxed is just the first step to finally achieving some level of security on the desktop. Going against the nearly 50 year long trend of 'all your applications run with the same rights as you' is a extremely tough task and requires changing and improving a lot of moving parts. Being able to control application access to your system through namespaces and file system images is just one part of the puzzle. (Getting rid of X is another. Layering LSM/Selinux/Apparmor over that is another, etc etc)

Plus Linux desktops desperately needs a universal package management system for applications. Having each and ever Linux distribution package the entire planet of software independently for each of their releases/branches is something that scales extremely poorly and leaves huge number of gaps. The internet has created a extremely long tail of software that just will never, ever, be supported by any distribution repositories yet application developers still want to write them and users will still want to use them. And it has absolutely nothing to do with 'doing it windows style'.

You can see this as evidenced by the fact that no Linux distribution ever really was able to make it easy to develop and redistribute video games, games engines, games related software/libraries/dependencies. There was huge number of attempts and distributions tried to package as much open source software as possible, but whatever they packaged became obsolete or old in short order. Users are loath to use a version of a game from 6 months ago if everybody else is playing the latest versions on public servers. As it stands right now if you want to install open source games or games built using open source software with proprietary content... the best way to do it is via Steam. Being at the mercy of a major proprietary corporation whose Linux support is effectively little more then a experiment at trying to manipulate Microsoft into behaving better isn't a good place to be.

Hopefully stuff like Flatpak can help reverse this trend.

Application isolation

Posted Aug 21, 2018 17:29 UTC (Tue) by atai (subscriber, #10977) [Link] (1 responses)

the scope of your interests is very narrow

Trolling

Posted Aug 21, 2018 21:04 UTC (Tue) by renox (guest, #23785) [Link]

Please refrain to put such low quality comment on LWN, reread the guidelines: "Please try to be polite, respectful, and informative".

Application isolation

Posted Aug 23, 2018 9:31 UTC (Thu) by mgedmin (subscriber, #34497) [Link] (3 responses)

I remember it the other way around:

- Snap was first, but only worked on Ubuntu
- xdg-app (old name of Flatpak) was announced as a cross-distro solution
- Canonical rushed ports of Snap to other distros, dropping the sandboxing in the name of expediency

I wasn't paying attention so I cannot comment on the current state of Snap on non-Ubuntu distros.

Application isolation

Posted Aug 23, 2018 9:52 UTC (Thu) by liw (subscriber, #6379) [Link] (2 responses)

Let's not rely on memories. The memory subsystem of human brains is even less reliable than floppies.

Wikipedia reports Snappy as being first release in December, 2014, which means it will have been in development for some time before that. (link)

Flapak's history page reports its origins as starting with Glick in 2007, with iterative evolution to what we now know as Flatpak via Glick2 and xdg-app.

Overall, it seems to me that Flatpak and Snappy have developed in parallel, learning from each other, in the way free software often does. There doesn't seem to be a clear answer to which one came first. I don't think it matters, either.

Application isolation

Posted Aug 23, 2018 23:20 UTC (Thu) by flussence (guest, #85566) [Link]

I'll add that 0install existed in 2005, so arguing which of these was first is a moot point. They're both NIH controlled by warring factions.

Application isolation

Posted Aug 25, 2018 3:19 UTC (Sat) by chipaca (subscriber, #28655) [Link]

Snap packages are the evolution of click packages, which were what the Ubuntu Phone used. FWIW.

Application isolation

Posted Aug 23, 2018 23:02 UTC (Thu) by flussence (guest, #85566) [Link]

Ironically, one of the things I've heard Flatpak is used for is running Windows games (usually pirated) with a bundled Wine.

Application isolation

Posted Aug 25, 2018 3:16 UTC (Sat) by chipaca (subscriber, #28655) [Link]

Funny how memory works.

The way I remember it, Canonical's work around isolated apps was out and in use years before flatpak was a thing.
We called it 'click' then, and used it on the Ubuntu Phone. This work predates even xdg-app by two or three years.
Then we built a 2.0 of that, and called it snap, and released _that_ in the 15.04 timeframe.
Even that was before flatpak.