I expect the Flatpak sandbox to protect my ~/ from getting cluttered by applications, not to protect me from any actually malicious software. The post’s premise seems misguided.
YES. I don’t understand this delusion people keep perpetuating. Flatpak has a MILD form of container sandboxing. For a real security sandbox we have Firejails or Bubble wrap.
Flatpak is, at it’s core, a software development and distribution packaging format. NOT a security implementation.
Sandboxing and security are very much features of Flatpak, even if they don’t advertise those to end users. Unfortunately, of the few desktop native applications Linux supports, very few of them actually work right when you sandbox them properly, so they’re underused. Any attempt at sandboxing also sets off the “they’re taking away MY FREEDOM” people on Linux forums, which doesn’t help Flatpak gain any kind of popularity.
A proper packaged Flatpak app should have the same level of security as an application you run in Firejail (or Docker, for that matter). All of this stuff works through the same APIs. Developers just have to enable them for their application.
Even popular Flatpaks actually don’t allow path escapes unless you’ve manually disabled the sandbox with flatseal. Unfortunately, very few Linux developers understand the concept of least privilege, and lots of Linux code has been written with the expectation that all paths are readable and/or writeable, so packagers just disable the security rather than alter the code.
You can plainly see how effective the sandbox will be based on your software store of choice. You can also restrict applications after installation, though that’ll probably break stuff.
It’s pretty funny how Snap manages to provide more security than Flatpak despite being such an objectively worse solution in almost all other aspects.
I always check my flatpak settings post install before running the app and adjust permissions according to need. I mean it does offer more security to me since it’s user installed, I can granularly update permissions and control more or less where and what is can touch.
Alternatives to this are SELinux,AppArmour and firejails which are slightly more inconvenient to use.
To me that is mostly secure,or secure enough.
Well and then there’s some immutable distros which might help overall.
Yeah, you can lock down Flatpaks quite tightly, but you’ll often need to do it manually, and there’s a good chance something breaks. It’s a bit unfortunate that applications don’t come with stricter permissions (and that you can install Flatpaks through any GUI but need to download an external tool to manage their permissions through the GUI…).
If you apply sensible restrictions and the application doesn’t crash, there’s a definite security benefit. Out of the box, though, most applications can touch your ~/.profile because they ask permission for your home directory, and 30 years of Linux tooling isn’t prepared to move from dotfiles in the home directory to a more manageable alternative.
On my Steam Deck Flatpaks have proven to work very reliably. I don’t understand why distros don’t come with a “user mode apt/pacman/dnf” that can install applications from a nornal repository without root access (I guess Nix, maybe?) but Flatpak solves this problem very well.
If we admit that then an app store where anyone can create an account and upload software becomes extremely problematic. This is especially true wherein clients autoupgrade very quickly.
Step one. Legit package a popular app
Step two. Wait for substantial uptake
Step three. Mix in some ad or malware and watch a tens of thousands get instantly owned.
I ignored flatpaks long enough, as everything could be installed as packages, without additional GBs of dependencies/libraries/runtimes of flatpaks, that duplicate the system ones. Recently started using immutable system, which assumes flatpaks is primary way to install apps. I found it is incredibly convenient when all your apps put their data in a single place, easier to backup and system looks clean without bunch of shit, apps create where they want.
In addition to own new code, bundled copies of libraries in packages introduces net new attack surface which isn’t patched via the regular distribution security patch process. The image decoding lib that allows remote code execution now exists in flatpaks independently from the one in /lib. Every flatpak vendor that contains it has to build and ship their own patched version of it. This is even more valid for any other libraries flatpaks include that don’t exist on the system. The most widely used Linux OSes come with security patching processes, expectations and sometimes guarantees. This new attack surface breaks those and the solution is security sandboxing. This approach has been proven in mobile app packaging and distribution systems. Android is a great example where apps are not trusted by default and vulnerable ones rarely cause collateral damage on otherwise up-to-date Android systems. This is an objective problem with the out-of-band distribution model allowed by flatpak and snap or any similar system, whether you care about it or not personally. It’s a well understood tradeoff in software development. It has to be addressed as adoption grows or we risk reducing Linux security to the levels of Windows where apps regularly bundle dependencies with no sandboxing whatsoever.
All Flatpaks are portable. There is no reason to use their repo usually though as Flathub often has more up to date, featureful, or upstream maintained versions instead.
I expect the Flatpak sandbox to protect my ~/ from getting cluttered by applications, not to protect me from any actually malicious software. The post’s premise seems misguided.
YES. I don’t understand this delusion people keep perpetuating. Flatpak has a MILD form of container sandboxing. For a real security sandbox we have Firejails or Bubble wrap.
Flatpak is, at it’s core, a software development and distribution packaging format. NOT a security implementation.
Sandboxing and security are very much features of Flatpak, even if they don’t advertise those to end users. Unfortunately, of the few desktop native applications Linux supports, very few of them actually work right when you sandbox them properly, so they’re underused. Any attempt at sandboxing also sets off the “they’re taking away MY FREEDOM” people on Linux forums, which doesn’t help Flatpak gain any kind of popularity.
A proper packaged Flatpak app should have the same level of security as an application you run in Firejail (or Docker, for that matter). All of this stuff works through the same APIs. Developers just have to enable them for their application.
Even popular Flatpaks actually don’t allow path escapes unless you’ve manually disabled the sandbox with flatseal. Unfortunately, very few Linux developers understand the concept of least privilege, and lots of Linux code has been written with the expectation that all paths are readable and/or writeable, so packagers just disable the security rather than alter the code.
You can plainly see how effective the sandbox will be based on your software store of choice. You can also restrict applications after installation, though that’ll probably break stuff.
It’s pretty funny how Snap manages to provide more security than Flatpak despite being such an objectively worse solution in almost all other aspects.
I always check my flatpak settings post install before running the app and adjust permissions according to need. I mean it does offer more security to me since it’s user installed, I can granularly update permissions and control more or less where and what is can touch.
Alternatives to this are SELinux,AppArmour and firejails which are slightly more inconvenient to use.
To me that is mostly secure,or secure enough.
Well and then there’s some immutable distros which might help overall.
Edit: paragraphs
Yeah, you can lock down Flatpaks quite tightly, but you’ll often need to do it manually, and there’s a good chance something breaks. It’s a bit unfortunate that applications don’t come with stricter permissions (and that you can install Flatpaks through any GUI but need to download an external tool to manage their permissions through the GUI…).
If you apply sensible restrictions and the application doesn’t crash, there’s a definite security benefit. Out of the box, though, most applications can touch your ~/.profile because they ask permission for your home directory, and 30 years of Linux tooling isn’t prepared to move from dotfiles in the home directory to a more manageable alternative.
On my Steam Deck Flatpaks have proven to work very reliably. I don’t understand why distros don’t come with a “user mode apt/pacman/dnf” that can install applications from a nornal repository without root access (I guess Nix, maybe?) but Flatpak solves this problem very well.
If we admit that then an app store where anyone can create an account and upload software becomes extremely problematic. This is especially true wherein clients autoupgrade very quickly.
Step one. Legit package a popular app Step two. Wait for substantial uptake Step three. Mix in some ad or malware and watch a tens of thousands get instantly owned.
Anybody can become a community packager for Debian, Fedora, etc.
Anyone can’t become a packager in 30 seconds in an automated process that they can’ t repeat the 47th time they transmit malware.
The process is identical.
You show up with a package. It gets a basic review. You are granted commit access to your package. You can push changes.
There is slightly more oversight in that another mentor often also has commit access but they can’t and don’t review everything.
I ignored flatpaks long enough, as everything could be installed as packages, without additional GBs of dependencies/libraries/runtimes of flatpaks, that duplicate the system ones. Recently started using immutable system, which assumes flatpaks is primary way to install apps. I found it is incredibly convenient when all your apps put their data in a single place, easier to backup and system looks clean without bunch of shit, apps create where they want.
Yeah, Flatpak was never meant to be a security mechanism. It is a convenient way to add security to userland though.
In addition to own new code, bundled copies of libraries in packages introduces net new attack surface which isn’t patched via the regular distribution security patch process. The image decoding lib that allows remote code execution now exists in flatpaks independently from the one in /lib. Every flatpak vendor that contains it has to build and ship their own patched version of it. This is even more valid for any other libraries flatpaks include that don’t exist on the system. The most widely used Linux OSes come with security patching processes, expectations and sometimes guarantees. This new attack surface breaks those and the solution is security sandboxing. This approach has been proven in mobile app packaging and distribution systems. Android is a great example where apps are not trusted by default and vulnerable ones rarely cause collateral damage on otherwise up-to-date Android systems. This is an objective problem with the out-of-band distribution model allowed by flatpak and snap or any similar system, whether you care about it or not personally. It’s a well understood tradeoff in software development. It has to be addressed as adoption grows or we risk reducing Linux security to the levels of Windows where apps regularly bundle dependencies with no sandboxing whatsoever.
So who’s that? Flathub and Fedora, the latter of who automate the Flatpak builds from distro packages anyway.
If you’re using a smaller distro which is not backed by a huge security team then this is probably an advantage of using Flatpak, not a negative.
Can the Fedora Flatpaks be browsed and downloaded for other distros?
Yes. All Flatpak apps can be used on any distro.
I’m using the Fedora Flatpak Firefox on Debian, because Fedora’s Flatpak runtime supports Kerberos authentication, the Flathub runtime doesn’t.
All Flatpaks are portable. There is no reason to use their repo usually though as Flathub often has more up to date, featureful, or upstream maintained versions instead.