Flatpak: A security nightmare – two years later

Re:Flatpak: A security nightmare – two years later by 013a on Friday October 02, 2020 @10:27AM (#24662944)

I think the industry has moved past believing that dynamic linking has a net security and usability benefit over static linking/sandboxing, even if you heavily bias toward preferring security. The three most "modern" and popular linux "package managers" made in the last decade (Snap, Flatpak, Docker) all bias toward static linking and sandboxing (in the case of docker, forced sandboxing, but the others are opt-in).

Sidenote: I include docker as a package manager in that list because recently I actually ran into a very large and popular command line application that, per their documentation, prefers distribution and execution via docker over anything else: aws-cli. They don't keep any other linux package managers up to date, despite having a package in snap and distributing a .tar.gz. They recommend invoking it via docker. Rather interesting, and I'm surprised we haven't seen a frontend for "docker as a pm" gain traction, to increase usability over "go into your .bashrc and alias aws=docker run aws/aws-cli:latest $*"

[ Parent | on HN ]

Re:Flatpak: A security nightmare – two years later by sempron64 on Friday October 02, 2020 @10:48AM (#24663166)

I think the industry has "moved past this" because for SaaS platforms, it takes a lot less labor to enforce sandboxing in-house applications on the cloud than to maintain dependencies across the shop. However, for an OS distribution to end users devices, where applications inevitably ask for an are granted MUCH more permissions than they need, this is not a safe model. It is CLEARLY superior for users and for operating system maintainers, or others responsible for user security, to update dependencies using the traditional dynamically linked model. No work needs to be done to consider the compilation tooling of each individual application.

The existence of Flatpak etc. is a misguided concession from the FOSS community to private businesses and to software developers who are used to packaging for the cloud. The model is not appropriate for desktop or mobile software -- there is a reason that filesystem access is extremely restricted or impossible on mobile platforms, and that even Android has moved to dynamically prompting for permissions when apps use them rather than bundling them into a single prompt at installation.

For Flatpak to work, we need MUCH heavier sandboxing, which will be detriment to productivity for desktop users for certain classes of applications, and may prevent many types of applications from being packageable as Flatpak. I think this is a fine compromise. I'm OK with installing Spotify as a Flatpak (given better security, not now) but keeping my webserver, database, file manager, terminal, programming language, and other "system" software in the OS repository.

[ Parent | on HN ]

Re:Flatpak: A security nightmare – two years later by hapless on Saturday October 03, 2020 @12:47PM (#24673170)

Snap, Flatpack, and Docker applications almost universally use dynamic linking.

They just use some combination of rpath fields and virtual filesystems to make sure the dynamic linker only inspects the paths mandated by the application author.

[ Parent | on HN ]

Re:Flatpak: A security nightmare – two years later by hedora on Friday October 02, 2020 @11:28AM (#24663606)

Docker dynamically links; you don’t need to recompile the world to update a docker image. You just regenerate the docker image.

[ Parent | on HN ]

Re:Flatpak: A security nightmare – two years later by 013a on Friday October 02, 2020 @11:34AM (#24663684)

It can dynamically link within the container, but as far as I know the container as a whole does not dynamically link with the outside world. Its effectively a chroot with a full system image inside that root filesystem.

And that's what we're talking about, effectively; how self-contained and sandboxed the package itself is.

[ Parent | on HN ]