I see that it can be slower because of having all the dependencies included with the flatpak itself instead of relying solely on whats installed on the system. I read that this means it isolates or sandboxes itself from the rest of the system.
Does this not mean that it can’t infect the rest of the system even if it had malware?
I have seen people say that it isnt good for security because sometimes they force you to use a specific version of certain dependencies that often times are outdated but I’m wondering why that would matter if it was truly sandboxed and isolated.
Do they mean that installing flatpak itself is a security risk or that also specific flatpaks can be security risks themselves?
I don’t think speed is an issue. They’re larger but all software loads dependencies from disk, flatpaks just have them bundled into a different location.
Snap did have some loading time issues but in terms of performance, I don’t think there was much measurable difference.
Ohai, let’s load our own individual copy of everything separately. Since - we hope - it’s all bult from pristine sources and unlikely to match versions, all that static code load isn’t shared with anything else.
It’s gonna load slower, take up buckets of space, and not care whether it’s some crusty old thing with sploits aplenty.
I miss when we had mentors to remind us not only How to be better, but also Why. My mentor was like if obi-wan was born in Dublin. His sarcasm cut deep if you could parse what he was saying.
There are vulnerabilities found in Flatpak’s sandboxing all the time so it’s pretty much broken. The opening speed on HDD systems is really really bad too. That’s why I only use Flatpak to install software that’s not available in my distro’s repos. Though I use Arch (btw) so distro packages being old isn’t an issue for me.
It’s still better than no sandbox at all, isn’t it? And who installs their OS on an HDD in 2024?
It’s still better than no sandbox at all, isn’t it?
I guess so.
And who installs their OS on an HDD in 2024?
Those who earn less than $5k a month (aka 80+% of people in the world).
Nearly all of my friends make less than $5k per month, and all of them have SSDs as the boot drive in their computer.
Yes. 1TB SSDs can be bought new for 50€, 500GB for even less. For some people this is expensive depending in the region (e.g. I also know someone who uses an HDD). But given the price of other pc parts it isn’t something to cheap out on (a 1TB/2TB HDD is also 50€).
Do you have current proof that there is security problems in the current stable version of Flatpak? Nothings perfect but bubblewrap should be pretty solid.
Well the sandboxing does help with trustworthy browsers so the websites can’t have excessive permissions. But relying on such a broken system isn’t a very good idea imo.
Go to flathub and check the permission of the application that you want to install. Normally they won’t have access to root directory, but could access your home dir. If they had any malicious intent, they could mess with your personal files.
I think there is another application that can restrict the permission scope on flathub itself.Also flatpaks are moving away from file system permissions towards portals. Though currently I wouldn’t see flatpak as much of a security measure.
Yeah but OP has a point regarding the libraries with known vulnerabilities. What if one of them gets exploited that allows remote malicious code execution and gives root access? I dunno how far the sandboxing goes in that regard.
The sandboxing is almost always better because it’s an extra layer.
Even if you gain root inside the container, you’re not necessarily even root on the host. So you have to exploit some software that has a known vulnerable library, trigger that in that single application that uses this particular library version, root or escape the container, and then root the host too.
The most likely outcome is it messes up your home folder and anything your user have access to, but more likely less.
Also, something with a known vulnerability doesn’t mean it’s triggerable. If you use say, a zip library and only use it to decompress your own assets, then it doesn’t matter what bugs it has, it will only ever decompress that one known good zip file. It’s only a problem if untrusted files gets involved that you can trick the user in causing them to be opened and trigger the exploit.
It’s not ideal to have outdated dependencies, but the sandboxing helps a lot, and the fact only a few apps have known vulnerable libraries further reduces the attack surface. You start having to chain a lot of exploits to do anything meaningful, and at that point you target those kind of efforts to bigger more valuable targets.
The sandboxing isn’t as much as, say, Docker containers. So I think access to memory and devices is still possible and can eventually get you access to the whole system. I would think.
And this isn’t limited to flatpaks but I would assume Snaps as well, which some software is now delivered in that format by Canonical, even for server software.
That’s interesting. I’ll have to look deeper into that
Docker is actually less secure from a sandboxing perspective as the docker daemon runs as root.
It would make more sense to compare to raw bubblewrap or podman.
Most flatpaks don’t have full access. You can grant permission via the file picker. (It happens automatically)
It’s not securely sandboxed like a Qube, but apps can have their permission to access files and such restricted. Malware can escape the sandbox, or apps may come with very permissive permissions.
Flatpak is supposed to be a sandbox, so if there is a vulnerable dependency then in theory any attack would be limited to the sandbox.
However, it depends on the software - some Flatpak need quite low level access to use, and in that case an attack or mlaware could get into the main system. And unfortunately Flatpak itself has vulnerabilities which cna negate the whole idea of a sandbox.
Flatpaks should be using up to date secure dependencies, but the reality is many do not. I would not rely on Flatpak for security. Even fully up to date Flatpaks can be insecure, and Flatpak itself have vulnerabilities that have needed fixing. And for many Flatpaks it’s not even clear who is maintaining them.
Flatpaks are useful for deploying software that’s just not available in your distros repos. But when deploying any software outside your repos - including App Image, build from source or 3rd party repos - you are opening your system up to security vulnerabilities. That’s the nature of installing 3rd party software. Flatpak offers some reassurance compared to some methods but it’s far from perfect.
If security is your prime concern, then Virtual Machines may be more secure route to sandboxing software (if done properly). Building from source would be the other option, as it means you take ont he responsibility for security by using the latest code including for dependencies. But there is no perfect option, it’s always about balancing risk vs convenience.
It’s also worth noting that software repos are also not perfect. But good distros invest a lot of time and effort in keeping them as up to date and secure as possible, usually via the hard work of volunteers.
I wish I saw this post yesterday before I installed VSCode from flathub, trying to get the terminal to see the same file system as my other shells. I got it fixed and learned a lot about flatpak.
Quick reminder: because flatpak hides your installation state from the system, part of flatpaks could be wildly out of date or toxic releases and your system will.not.care nor even show you anything about it.
Enterprise tools - or normal stuff that acts like them - that check remotely what you have installed and let you know you’re potentially out of date (like tenable but not junk) will not learn anything about flatpak content.
Good luck. Every good thing about enterprise packaging is thrown out the window. Flatpaks are toxic.
Linux users will do anything to avoid using an honest-to-god command-line package manager.
Flatpak does NOT provide sandboxing. It containerises your applications. It’s better for permission management but by no means makes the system invulnerable to malware.
The flatpak sandbox shouldn’t be considered secure against malware. It is more of a loose sandbox.
It is technically possible for a flatpak to ship a insecure library. However, that’s not unique to flatpak and I’ve never actually heard of that happening (I’m sure it had)
In short: No. It’s getting better, but Flatpak is by no means secure. Think of it as a Windows .exe or .msi with some (not that hardened) rights management.
In addition, Flatpaks afe often community made and not even “signed” (which is not really a thing in Flatpak to begin with (yet) ((afaik))).
Something really secure would be a container, something really, really secure would be a VM, something really, really, really secure would be a separate machine. Flatpak is less secure than the least secure thing in this enumeration.
I don’t think they have bad security. It should be impossible to actually break with the sandbox with the currently known information. The vulnerability I could see is human related. The sandbox can’t help you if you give it your login information.
Flatpaks are containers. They do have a lot of holes though.
They have there own tradeoffs. The weakness is usually the user.
I see that it can be slower because of having all the dependencies included with the flatpak itself instead of relying solely on whats installed on the system.
No. Packing its own libraries wouldn’t make it slower. If anything it would be the extra access checks added by the sandbox (which is optional FWIW, apps don’t have to use it). I haven’t ever used Flatpak but I would assume the sandbox impact is minimal if at all noticeable.
There aren’t any “extra access checks” to my knowledge. It’s just the same regular access checks applied to a different set of circumstances.
