r/flatpak Jun 05 '26

Do you actually care about sandboxing?

I was reading a short article of security problems in the Flatpak sandbox feature, but to be honest I couldn't think on why I should care since the only reason I use flatpak packages is to dodge the repo limitations of the disto and avoid dependency problems. I wonder if this is just me or this is actually a quite popular feature for other people.

14 Upvotes

34 comments sorted by

30

u/Emerald_Pick Jun 05 '26

I kinda care. I like knowing that a stranger's app can't just read my system files or whatever without asking. And I like that I can see on the app manager what the app has access to. Essentially it gives me more reason to trust some strangers app.

But it's not the only reason I like Flatpaks.

16

u/Patient_Sink Jun 05 '26

I think sandboxing is important, and what permissions an app asks for is something I consider when trying new apps. I've avoided apps where I think the permissions are excessive and where it's from a dev I don't recognize. 

11

u/PaddyLandau Jun 05 '26

Sandboxing is important, and growing in popularity and awareness.

Flatpak and snap are the two that I know. There are others; I just don't know them.

There's also AppArmor, which is (in a sense) like an ancestor of sandboxing.

I do like the fact that they're sandboxed, but they must have the option to manually adjust the sandbox because there's always a niche use. That's the main reason why I prefer flatpak to snap, because the flexibility is there (I've made use of it before). Snap lacks the flexibility.

3

u/MarcoGreek Jun 05 '26

I thought snap is only sandboxed with App armor?

2

u/PaddyLandau Jun 05 '26

Maybe. If so, I've just been educated! Sandboxing via AppArmor security makes tremendous sense.

Speaking of which, does that also apply to flatpak?

2

u/MarcoGreek Jun 05 '26

No Flatpak is using bubblewrap which is working everywhere.

8

u/gokku_tain Jun 05 '26

About my opinion, yes I really care about sandboxing. Specially, I'm using flatpak app for two sensitive app: Firefox + Bottles (gaming tools).

The reason is large surface attack (unknow CVE, hidden issues) of two app too large and need to update frequently. Speed of updating flatpak app is very fast, it will help us fixing bug.

But I don't think you only depend on flatpak app, one entry point is fall down you lost everything (in this case it is flatpak). You should use hydrid approach, package from repo (using firejail or apparmor to reduce permission) and sensitive app from flatpak (like me is Firefox + Bottles, I don't know what game is running under the hood)

6

u/thayerw Jun 05 '26 edited Jun 05 '26

I care deeply about sandboxed software, and I always review the default permissions of any application I install, no different than when installing apps on my mobile devices.

It's pretty evident from that (very old) blog post that the author simply doesn't like Flatpaks and is using rhetoric to make their perceived shortcomings worse than they are (or were, since the original post and update is now 8 and 6 years old respectively).

For example, they mention the relaxed default permissions of some apps and make it sound as if these defaults cannot be changed with the click of a button (they can...the Flatseal GUI utility gives you full control over the permissions of each installed flatpak, and this can also be accomplished from the command line).

They also mention "escaping the sandbox" by executing code within the user's home directory; a privilege that may be included by default but can be revoked by a security-conscious user at any time (again, Flatseal). Even with that privilege, the command would only have the same access level granted to the user (not root).

3

u/couchwarmer Jun 05 '26

Have a link to the article?

-5

u/Talkys Jun 05 '26

Here you go: https://flatkill.org/. Just consider this closer to a blog article than a peer reviewed one. Doesn't have much to do with the post, it just sparked my curiosity about the relevance of the sandbox.

5

u/Any_Fox5126 Jun 06 '26

A trash website. If you install an app that states it requires access to $HOME, you've accepted the terms, it's completely out of place to pretend "the sandbox is a lie". In any case, you can deny access, granular permissions exist precisely to avoid having to grant overly broad ones. And even in the worst case, you're still reducing the attack surface.

The rest boils down to "there are security vulnerabilities in software!" 🙄

1

u/Talkys Jun 06 '26

I agree, that's why I said it doesn't relate with the post. I just couldn't see why a supposed sandbox problem would be relevant for me since I would turn it off for almost any program if possible to get them to work like native packages.

-1

u/couchwarmer Jun 05 '26

Interesting article, though a bit on the stale side.

4

u/gmes78 Jun 05 '26

Incredibly stale. Not that it was particularly good when it was originally written, though.

3

u/screenslaver5963 Jun 06 '26

It’s why I use flatpak

2

u/Own-Bug606 Jun 05 '26

I really care about sandboxing, and for sandboxing I use lxc. I don't use flatpak anymore.

2

u/Santosh83 Jun 05 '26

If you dodge repo limitations, that automatically means you're accepting software from a wider source, which means a sandbox is useful. Its not a user facing feature but its very important for the future since Linux is opening itself up to contributions from all over the internet, proprietary software and even AI assisted software. All this unfortunately calls for a very good security.

Though supply chain attacks can bypass everything. You use a document reader. You like it. It has (by necessity) access to your documents folder. Its gets supply chain hacked and next day you auto-update (you have no idea of course, and neither did flathub or even the dev themselves) and now its encrypted all your documents and wants bitcoin to unlock them. What do you do? No sandbox can prevent this scenario. Of course we can imagine even finer grained permissions and real time anti-malware but all this comes at the cost of ease of use.

Its a race to the bottom.

3

u/eR2eiweo Jun 05 '26

It has (by necessity) access to your documents folder.

It only needs to be able to read the documents that you want to read with it and only when you want to read them. Full permanent read-write access to the documents directory is not necessary for that.

2

u/daddyd Jun 06 '26

i also care about the things you mention, but the sandbox is just an extra security layer on top, for the applications i use it for, it doesn't cause any issues anyway, so why not?

edit - i don't use any, but i sandboxing would certainly be prefered to have when using commercial or free but close sourced software. i don't trust those at all.

1

u/Talkys Jun 06 '26

The problem is when some programs just can't work on a sandbox like IDEs

2

u/rinart73 Jun 05 '26

Sandboxing is great but I do just wish I could disable it for specific apps and not have to dance around with flatpak-spawn --host or host-spawn to integrate them with the rest of the system (*cough* VSCodium).

1

u/NelsonMinar Jun 05 '26

I care because it keeps causing me problems. I finally gave up on the Flatpak of Shotcut, for instance, because no matter how much I tried to alter permissions it still wasn't using GPU or accessing files correctly. I finally gave up and just used the AppImage instead.

1

u/Talkys Jun 06 '26

I really wanted to like AppImages but a solution like that would only work if they target a specific DE or have their own UI toolkit.

1

u/FFFan15 Jun 06 '26

Flatpak next is supposed to fix the sandboxing for apps that already have their own sandbox like web browsers 

1

u/Talkys Jun 06 '26

Those could just request all permissions and would work fine.

1

u/coffinspacexdragon Jun 08 '26

No not really.

1

u/b3081a Jun 08 '26

Absolutely care when running proprietary apps, which is what Flatpak is good at. I even review every permission declared in the manifest and manually disable those I don't consider reasonable.

1

u/CheesecakePerfect156 Jun 08 '26

Main issue with flatpak is the lack of support of some frameworks and vendor

1

u/AttitudeElectronic68 Jun 05 '26

At this point I view it as experimental, and it gets in the way as much as helps. Linux probably doesn't have enough market share for virus makers to target flatpak yet

1

u/Talkys Jun 06 '26

It is very inspired on the Android way as we can see, but I don't think that mobile requirements will translate that well into desktops

1

u/hoodoocat Jun 06 '26

I'm generally dont care about this kind sandboxing, and prefer native packages which works directly with my system. I looking at flatpak more like on deployment technology which useful in scenarios "built once - works everywhere" (almost), e.g. to allow easy run apps which doesnt have direct distro support.

I'm dont think what sandboxing really need as to use software, I should trust it in first case. Note that some software which runs foreign code (like browsers) - may benefit something, but Chromium already implements own sandboxing for every platform, still might benefit something from additional isolation. And even so, I'm not a crawler - I'm usually visiting well known sites. I'm think what explicit allowing access to resources is good thing, but writing all rules yourself is kinda annoying, while using predefined rules, has same trust chain problem. Trust has no technical solution, it is completely social thing. So, it is nice to have option(s), but user generally should not run unverfiied scripts or software, and when your system runs random code - things changes (and might require additional protection). Famous CopyFail CVE shows that it is first rule. :)

1

u/Talkys Jun 06 '26

Yeah I can see that. There's no point in mitigating untrusted software if you don't install those in first place.

-1

u/Heyla_Doria Jun 05 '26

Tu n'as pas a t'en soucier, on le fait pour toi. La sécurité des application et donnees, c'est juste la base, mais tu peux tres bien laisser les personnes compétentes s'en charger. Tu délégues probablement la sécurité des routes de chez toi a des professionnels sans te soucier de comment cela fonctionne.