@madaidan looking at archwiki for bubblewrap and firejail and bubblewrap low capabilities [link,link] of sandboxing pulseadiuo , X11… just not worth any effort towards it over firejail.
plus its already installed now in WS anyway, what is your point you want to reach?
Firejail can’t sandbox pulseaudio. It just blacklists a few pulseaudio files so it can’t be accessed. I’ve already said replicating this with bubblewrap is easy and X11 sandboxing with bubblewrap is still easy with xpra.
Please point out one actual important feature that cannot be replicated with bubblewrap.
So uninstall it. Whonix shouldn’t be adding privilege escalation holes to it.
I am in favor of bubblewrap. It makes no sense to choose firejail over it with overwhelming evidence to the opposite.
Tor Browser implemented a sandbox using it as a proof of concept a while back.
Nothing actually can properly sandbox pulseaudio as pulseaudio access control is still a work in progress Access Control – Development Documentation – PulseAudio
bubblewrap not only exposes security vulnerabilities in the kernel but also in the window compositor. Users should be aware that running untrustworthy code in Bubblewrap is still not safe.
So its already done with firejail so whats the point just changing to bubblewrap?
supports of GUI list like firetools. (thats what im thinking atm)
your argument towards oh look has vulnerability like this or that one its pointless because we are talking about software not holy software so yes had vulnerability but fixed because its active and no threat using it atm.
Question: Do you guarantee Bubblewrap wont have these issues? and if not will you also suggest removing it?
Firejail does the exact same. You cannot prevent this without using a VM.
I’ve already told you this yet you’re still quoting this. Why are you knowingly painting an inaccurate picture?
Firejail is insecure.
That’s not important and is unneeded. We can even make our own bwraptools program if you really want to.
Read everything said. Firejail has too large attack surface. Just because one vulnerability was fixed doesn’t mean there are no more vulnerabilities. A program with large attack surface and being setuid is a perfect way to get a bunch of priv esc vulnerabilities.
Just look at what experts such as Micay say.
Bubblewrap doesn’t have these issues as it has far less attack surface. I’ve also said why above.
Bubblewrap is actually recommended by experts on this topic such as Daniel Micay (yet again).
use bubblewrap if you need more functionality
I know and thats my point when i said just same done with firejail.
proves? fixed CVEs/Vulnerabilities just unconsidered. give us design flaws that give insecurity to running applications within it.
ah i see, well dont believe in that too much because no body gonna do it simply because we dont have experts in GUI anyway let alone time. ← This is a user friendly advantage over bubblewrap.
sorry i dont buy it because looking at the activities of both projects:
i think bubblewrap if its used in that extensive i dont believe in which one has less CVEs.
Micay i dont believe in him much, thus i have asked Alexendre Oliva about his(micay) work on harden linux and firejail and gonna share his answer once he replied.
That doesn’t make sense.
Already explained. I won’t repeat myself.
It’s easy to do it. I can write a bash script that does this in zenity really easily.
An equivalent to firetools shouldn’t even be needed as all apps should automatically be sandboxed.
What? The activity of the projects doesn’t determine it’s security.
What?
Micay is an expert. He knows more than all of us.
Alexandre Oliva is a free software activist, not a security expert.
I don’t see why you’re pushing for firejail so hard when the evidence clearly shows it’s not a good idea.
@madaidan citation needed , i dont see point throwing whole security tool used by thousands and one (if hes one) expert says no without very strong arguments on the table.
If the conclusion finalized that it has a security opposite to the users im the first one whos going to write about deleting it.
Alexandre Oliva has worked on Linux to produce Linux-libre since ages, hes not just activist and possibly hes the next president of FSF (because hes vice president)
I have given many already.
Bubblewrap is also used by thousands. It’s used internally by flatpak and likely has far more users than firejail.
This isn’t a popularity contest either.
I gave two examples.
He is one. He has submitted tons of hardening patches upstream to the Linux kernel, OpenBSD, AOSP and more. He’s the guy behind linux-hardened, GrapheneOS, CopperheadOS, hardened_malloc and more. He was even part of the KSPP.
I don’t see why you’re so against him.
He does have strong arguments.
I’ve already proved it’s harmful to security.
And?
Still not a security expert and still irrelevant to this discussion. You’re trusting free software advocates over actual security experts who know what they’re doing.
i dont want to repeat my points which are opposing the arguments you are proposing thus i will wait to collect experts ideas about that, but here is where the good start begin:
you said:
can you start doing that and let us see how far its user friendly?
I haven’t mentally processed all input in this thread yet.
I don’t want to act too quickly here (within days). After the amount of work that has flown into firejail (sunken cost fallacy…), it would be awful to remove it in case security experts are undecided about it. Therefore taking more time to find positives about it.
bubblewrap: I wouldn’t want to act too quickly here too at the risk of further wasted effort. This isn’t a popularity contest but a (less) active or inactive upstream which leads to it being deprecated would result in wasted effort too. This also needs to be researched.
Asked @nurmagoz to help finding positive statements about firejail and negative statements about bubblewrap. (Quite a bias on a second thought.) This is a result of it:
I have already done that and no, free software guys aren’t experts in this topic.
https://paste.debian.net/hidden/e16a9784/
Assuming the bubblewrap sandboxes are stored in /etc/bwrap/.
Bubblewrap isn’t less active. They’re just wary of new features due to not wanting to increase attack surface.
Obviously asking on the firejail github repo will get biased responses.
summary
firejail security
Can’t rely too much on Daniel Micay as security export because he’s (often justified…) critical on “everything”… Could as well as give up and go home following that sentiment. Reference: Daniel Micay Quotes
Firejail developers might be bias towards firejail.
Bubblewrap developers might be bias towards bubblewrap.
Under the bias thesis, both candidates aren’t ideal expert opinions here on judging the security of each tool vs each other. Their input is valued nonetheless.
Tried to wrap my head around this issue. Made some notes here:
Dev/Firejail - Kicksecure
Trying to come up with essential questions.
Please keep expert opinions pro/contra firejail / bubblewrap / apparmor / etc. coming.
installation by default
Whonix doesn’t enable any firejail / bubblewrap profiles for anything by default yet. All such profiles are opt-in.
Whonix comes with some apparmor profiles by default. Those for its own software and those profiles maintained by Debian. Other profiles are opt-in.
Decided to no longer install firejail by default due to
Currently Whonix has a by default a higher attack surface (due to firejail installed by default) but no security advantages (not making use by default of any firejail profiles).
Firejail was only installed decided to become installed by default for better usability. To make writing firejail profiles easier. This could be undone since we did not get any new profiles anyhow.
At the moment, major attack surface realistically is the browser, Tor Browser. If hypothetically upstream, The Tor Project maintained a firejail profile, then I would think that the security advantages outweight the security disadvantages of it. Until in-the-wild attacks proof otherwise. That would be a reason to keep firejail installed by default.
SecBrowser depends on firejail and uses it by default. But SecBrowser isn’t Whonix. For SecBrowser I’ll keep firejail enabled by default until I am convinced that it does more harm than good against realistic attacks (what happened previously in-the-wild).
future reconsideration for re-installation of firejail
He’s only critical on things that deserve it.
The recent thread shows a majority of people “pro-firejail”. I’m really the only one “pro-bubblewrap”.
Firejail’s large attack surface is already well known.
It may have made privilege escalations easier. I originally thought you meant if it helped those attacks, now I see you meant if it helped against. Those attacks are mainly IP leaks which firejail doesn’t try to prevent.
It’s one of the most popular linux sandboxing programs and is a very vulnerable target. It’s not very unlikely.
There’s more pro bubblewrap quotes by Micay (these have nothing to do with firejail).
Everything else is better served by https://github.com/projectatomic/bubblewrap.
The problem also isn’t likely to change even years from now. It’s still going to be a poorly designed feature with much better approaches like the one taken by bubblewrap which exposes much less attack surface.
There are projects like flatpak / bubblewrap providing alternatives to user namespaces that are more secure.
After reading Firejail devs’ responses I really respect them. That’s some of the most neutral and helpful commentary I’ve seen.
netblue30 plainly recommends that for our threat model we focus on a tight full system MAC policy and forget about sandboxing altogether as it is meant to raise the security baseline of single user systems rather than be a solution for servers. That’s the main thing and you should stop reading here if you’re wondering what to do next.
https://github.com/netblue30/firejail/issues/3046#issuecomment-555326127
I don’t agree with that. Namespaces and seccomp are extremely important and apparmor doesn’t use them.
Seccomp especially is important as it can greatly reduce kernel attack surface.
They admit for stuff running outside the sandbox the attack surface is larger than bubblewrap and theoretically enables easier privilege escalation. On the other-hand this doesn’t apply to stuff in the sandbox. Firejail’s comprehensive selection of application profiles would limit this scenario.
Once inside a sandbox - firejail, bubblewrap, or any other seccomp sandbox - you can not exploit any SUID executable present in the system. It has to do with the way seccomp is handled by the kernel. The attack surface of the program that configured seccomp becomes irrelevant. In other words, if you get control of a firefox running in a sandbox, the kernel wouldn’t let you exploit the program that started the sandbox.
Meanwhile since you have the skills to actually forge a solution that combines the best of both world’s we can have our cake and eat it too:
Yes, bublewrap has less additional attack surface for scenario 2 but merely installing bubblewrap does nothing for scenario 1 unless someone write special wrapper for it with profiles for many specific apps. Something like that, let’s call it Firewrap or Bubblejail would be interesting, perhaps more secure solution than firejail but for now it doesn’t exist.
How would bubblewrap in the Workstation work? IDoes bubblewrap have commands and profiles that need to be implemented on a per-app basis, or is this done through config files? I saw the comment about using wrappers for it, but am not exactly sure
It doesn’t really have profiles. It’s only meant to be used as a command. To create a “profile” you need to create a wrapper script for the program that uses bwrap. e.g.:
bwrap \
--dev-bind / / \
--unshare-all \
/usr/bin/torbrowser
This is a very basic example. See the other example I linked above to get a better idea.