Flatpak 1.16.4 released - bringing important security fixes for sandbox escape & deleting host files

[-]

ElvishJerricco@reddit

People when Apple fixes an iOS sandbox escape: Wow that could have been bad; might have already been bad for some. Glad they fixed it.

People when Flatpak fixes a sandbox escape: See?? Flatpak sucks. Sandboxes have no value.

I'm obviously exaggerating but that sure is how it feels sometimes.

[-]

Sandbox is only as good as it's design and implementation, as a general rule I can assure you that more complexity == more security issues. Having one sandbox everyone relies on is a mistake and companies like valve forcing their customers into this paradigm by insisting we all use bwrap should stop acting so foolishly.

[-]

dontquestionmyaction@reddit

Not that I don't agree with some of your points, but bubblewrap is really an incredibly simple sandbox. I think your beef is more with different implementations like Firejail.

[-]

2rad0@reddit

No my post clearly states my beef is with companies like valve forcing their users to use one specific sandbox implementation. My beef is with lack of choice and lazy profit driven companies.

[-]

dnu-pdjdjdidndjs@reddit

you clearly didnt read all the code if this is your conclusion

bwrap has an SUID mode where it intentionally drops capabilities

The default codepath doesnt use this at all

bwrap could certainly be even simpler though especially if you take a stance like linux 7.0 baseline, userns only, and only use the new apis like the tree thing.

BTW I bet you didnt even know that userns is a potential security issue if selinux isnt restricting permission to only specific bins

[-]

2rad0@reddit

you clearly didnt read all the code if this is your conclusion

What exactly do you think I have concluded other than I'm not using bwrap at all in it's current form, and don't wish to provide any further charity work auditing it's source other than pointing out the obvious red flags that I can find in 10 minutes?

BTW I bet you didnt even know that userns [...]

I never enable userns because it's a well known security problem, nor do I use selinux because it's source code and build system are utterly broken while also dependeing on extended attributes which I also do not enable in any of my kernels, so neither of those weird contraptions affect me.

[-]

dnu-pdjdjdidndjs@reddit

did you forget you questioned why it uses capabilities

What sandbox do you use or are you criticizing bubblewrap in comparison to rawdogging

[-]

2rad0@reddit

I was disturbed by it's use of ambient capabilities, those are non-traditional capabilities where they won't be automatically dropped after execve, and were only added around linux V4.0 or so. Normal inheritable capabilities only persist across a single execve call, but ambient caps will last for the remaining lifetime of the process as long as nothing else changes in the processes capability bitset. It's compeltely seperate from my criticism of using CAP_SYSP_PTRACE.

What sandbox do you use or are you criticizing bubblewrap in comparison to rawdogging

I wrote my own sandbox pre linux v4.0 and it's the only setuid program I allow on my OS, but that is not relevant to my criticisms of other setuid programs that a proprietary program forces you to have installed. I would in fact prefer "rawdogging" steam-launcher by creating a dedicated user for it instead of giving a proprietary networked program the potential to elevate privileges.

[-]

dnu-pdjdjdidndjs@reddit

bwrap doesnt even run right now if it has ambient capabilities so idk what you mean

[-]

2rad0@reddit

bwrap doesnt even run right now if it has ambient capabilities so idk what you mean

It's in the source code that I spent a whopping 10 minutes looking at and picking out red flags. If you look at the function that drops capabilities it doesn't drop them when the ambient caps are requested (because otherwise ambient caps dont work). Your distro maybe doesn't compile it with support for them, or it is broken as you say.

[-]

dnu-pdjdjdidndjs@reddit

theres literally an open issue complaining that it doesnt work in containers if it has ambient capabilities

[-]

dontquestionmyaction@reddit

If argument list length is what you see as an indication of complexity, I have a bridge to sell you. Good lord.

[-]

6e1a08c8047143c6869@reddit

No my post clearly states my beef is with companies like valve forcing their customers to use one specific sandbox implementation.

How do they force you to use it? You can just extract the game binary and run it without the sandbox (assuming you manage to setup the required libraries it needs to link against)? Or duct tape together a new runtime with whatever sandbox you want to use?

.... and CAP_SYS_PTRACE

What is your issue with that? The comments state pretty clearly why that is needed, no?

I was already never going to use it and I don't need any reasons other than the insane list of arguments you can pass it:

Wow, this low level sandboxing tool sure has a lot of parameters! Even firefox only has 41! I can't believe bubblewrap is so bloated in comparison!

[-]

2rad0@reddit

You can just [...]

Oh all you have to do is just... spare me this attempt at justifying valve's lazy decision to force a specific third party sandbox onto it's customers. Have you even tried to run steam without bwrap? Because I have and you are wildly understating the difficulty. what you "just" have to do is create a wrapper that perfectly emulates the smörgåsbord of bwrap API/arguments. all you have to do is "just" reimplement bwrap exactly as valve/steam-launcher decides to use it from one update to the next. They clearly don't want my patronage, since they don't offer a way to run steam without bwrap at all, so I'll continue not using it until I get the motivation to convert bwrap's excessive abuse of arguments to my sandbox's config format.

What is your issue with that? The comments state pretty clearly why that is needed, no?

Whats my issue and every security researchers issue with ptrace? I'm not going to write a wall of text that has been covered extensively in detail on LKML and elsewhere, I will just note that ptrace(2) is not needed for sandboxing. and no, that specific capability is not needed. If you read the manual page the comment cites it says:

Permission to dereference or read (readlink(2)) these symbolic links is
governed by a ptrace access mode PTRACE_MODE_READ_FSCREDS check; see
ptrace(2).

ADDITIONALLY, watson, ptrace(2) says it only needs PTRACE_MODE_READ. Maybe they really require it as an easy way to bypass yama restrictions (yama security module exists because ptrace is a notorious security hole) that may be set by the distro? I'm not even sure what feature of the as another commentator put it "incredibly simple sandbox" would require a yama overriding ptrace monitor?

Wow, this low level sandboxing tool sure has a lot of parameters! Even firefox only has 41! I can't believe bubblewrap is so bloated in comparison!

Firefox's sole purpose is not to create a secure compartment for running untrusted native binaries, I'm not sure why you mention it here. A program that elevates privileges should keep such user controlled arguments to a minimum, believing otherwise is a dangerous position to take and defies all known best practices for writing such programs. The more combinations of state you can control when running such a program introduces potential points of exploitation. each argument expands the attack surface.

Sometimes you have to stand up for yourself and tell people requesting certain features "NO, bad dog!". Unless you want to create a rats nest of command line arguments and force other sandboxes to adopt a weird API with a large set of features. IMO bwrap needs to go back to the drawing board and think about what the people using it really want, and throw all the other garbage out. first thing to the rubbish bin is how you have to pass it thousands of kilobytes of arguments just to setup an environment, when I was strace-ing steam launcher the argument list was definitely ofer 4096 bytes which caught me by surprise and was the initial red flag that made me think the design is improper. No amount of sarcasm or attempted justifications will cause me to think otherwise or decide to spend additional time highlighting more flaws in the program, so I think you might be wasting your time.

[-]

Huge_Lingonberry5888@reddit

Same for Snap, i prefer flatpak instead of Snap - but all boils down to updates and keeping the app inside also up-to date...

[-]

Scandiberian@reddit

You know you can delete snap and install Flatpak on Ubuntu based distros with zero issues, right?

[-]

Huge_Lingonberry5888@reddit

Well, if i have snap..i am probably on the Ubuntu family :) as my badge shows up :D and yes i did it already.

[-]

Scandiberian@reddit

Oh okay, I misunderstood your comment. Thought you were lamenting having to use Snaps due to being on Kubuntu.

Thankfully on Linux we don’t have to accept anything we don’t like if alternatives exist. :)

[-]

Scandiberian@reddit

A fellow Nixling in the wild? Anyways you’re correct, the Linux community is overly cynical and always critical of clearly good things.

The endless wars between KDE and GNOME for example, crazy how people seethe over the existence of another DE.

[-]

mrtruthiness@reddit

People when Apple fixes an iOS sandbox escape: Wow that could have been bad; might have already been bad for some. Glad they fixed it.

People when Flatpak fixes a sandbox escape: See?? Flatpak sucks. Sandboxes have no value.

I'm obviously exaggerating but that sure is how it feels sometimes.

That's a bias in you perception. You are remembering and putting more weight and emphasis on the comments that bother you the most. You're bothered when people excuse Apple's issues ... so you put more weight on that and your perception is distorted. Similarly, you're bothered when people criticize flatpak's issues ... so you put more weight on that and your perception is distorted.

You have a negative bias. Which, while not healthy (it's upsetting), is better IMO that others who dismiss/ignore criticism and, conversely, focus on self-confirming articles.

[-]

Due_Friendship_8597@reddit

Updated Flatpak Version 1.16.6 on Apr 11.

[-]

Separate-Royal9962@reddit

Sandbox escape keeps being a recurring pattern — Flatpak, Docker, now even AI models. At some point we need to accept that sandboxing is a game of whack-a-mole and look at what the filesystem itself can enforce structurally, independent of the sandboxed process.

[-]

Dangerous-Report8517@reddit

“Security sometimes fails therefore we shouldn’t bother”

Filesystem permissions already exist and they were grossly inadequate, that’s the entire reason we have sandboxing in the first place. Could we have more granular protections? Probably, but it would take almost as much effort as tightening up Flatpak with far less benefit since it would provide no process isolation at all, and process isolation is at least as important as file access control since an app could bypass file access restrictions by just accessing them indirectly through a different app

[-]

6e1a08c8047143c6869@reddit

At some point we need to accept that sandboxing is a game of whack-a-mole and look at what the filesystem itself can enforce structurally, independent of the sandboxed process.

Why not both? Defense in depth is generally what you want.

[-]

Ok-Winner-6589@reddit

I don't want to give Discord while access to my files Buddy. Neither you want Reddit to know which apps you have installed on your device

[-]

sensitiveCube@reddit

I was really afraid Flatpak was dead

[-]

BinkReddit@reddit

I love Flatpak, but the constant sandbox escapes really kill one of its greatest value positions.

[-]

nobody-5890@reddit

Vulnerabilities exist in all software. What really matters is having them responsibility disclosed before they can become day-0s. Which seems to be the case here.

Also, keep in mind that a sandbox is still useful for normal apps. Normal apps aren't trying to break the sandbox in malicious ways. But if that app had a severe bug, say, tried to recursively delete a directory "$HOME/$SOMEPATH" but $SOMEPATH was an empty string, it helps limit damage (if the app was properly sandboxed, without real home permission).

[-]

Classic_Mud_51@reddit

Also good for browsers. Even when you get something malicious that bypasses a browser sandbox, it won’t expect flatpak. Then there’s stuff like discord or ms teams that you don’t want being able to overstep their boundaries

[-]

WishboneFar@reddit

I read somewhere that flatpak sandboxing downgrades browser's native sandboxing. Is it true?

[-]

Classic_Mud_51@reddit

Oh yeah, I forgot about that. I will say that’s one problem I believe snap doesn’t have. If they can get flatpak’s sandboxing to work on the outside of the browser, that’d be perfect.

[-]

nobody-5890@reddit

Yes, flatpak currently blocks access to unprivileged user namespaces which both Firefox and Chromium use to isolate browser processes.

So while the browser has less access to your system, the browser itself is more vulnerable to attack.

For Chromium, there's patches and a wrapper to redirect user namespace to use the flatpak sandbox instead, but from what I've read, this is worse than Chromium's native sandbox.

[-]

Imaginary-Nail-9893@reddit

I love that the default for most Linux users is something that at least has a lock on the door no matter how shitty the lock is. It isn't a big privacy vialation on like windows for a random app you run to dig through your pictures or documents folder because those things are just sitting there. In order for a app to do so for nooby Linux users it would need to stomp on their lock, and the implication of having a lock by default definitely effects the culture. Its been a overall positive.

[-]