Think about service providers (government, banking, messaging, streaming, gaming). To participate in life we might depend on some of their services but don’t fully trust these parties. Flatpak is not secure/sandboxed enough to run untrusted apps. Meanwhile on Android the situation looks much better.
That’s a feature not a bug. Under flathub, the original author of the software (for verified apps at least) knows what is the best configuration to ship for their package.
ATM. You are not trusting flathub when installing a flatpak. You are trusting the application’s author. Maybe in the future, flathub would introduce restrictions on certain permissions but we would be speculating at that point.
Yes, I’m trusting flathub. LOL about people repackaging applications. Wait until they find out the Linux distro they use is a collection of software repackaged by 3rd parties. 😂
Userland hasn’t had any concept of security, so it’s nice people are trying to fix it.
I’m mostly using Flatpaks on Tumbleweed, I only use the package manager if I can’t find a Flatpak version. Reason for that is that with Flatpak I can precisely know what I manually installed, as Tumbleweed lacks a proper easy way of getting a list of user installed packages
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.
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.
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.
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.
This is generally good advice. Would you run the program without a sandbox? No? Then you probably shouldn't run it inside a sandbox either.
You can never be sure that the program isn't using a flaw in the sandbox to break out or is just piggybacking onto a whitelisted action that is required for the program's basic functionality.
And if some program requires r/w for your entire home directory and network access then you might as well not use a sandbox in the first place because it can already do everything useful that it needs to do.
As someone who struggled quite a bit to learn Nix, I’d say start small. Install Nix the package manager on any old distro you’re familiar with and play with standalone Home Manager. Enable one program here and there, have it manage your shells and CLI apps, set environment variables and write files. It’s something you can immediately see the effects of and feels pretty rewarding, so I think it’s a great place to start.
I also happened upon this video series a few days ago and it’s a great resource, easy to parse and walks you through not only the basics but how to look around and investigate in the REPL when you want to figure something out.
Add comment