It is. Firejail doesn’t offer nearly as good file path whitelisting than AppArmor does. Firejail also can’t do many things AppArmor can such as managing ptrace or signals.
It’s also good defense in depth. If there’s a vulnerability in Firejail which isn’t unlikely then AppArmor will still restrict the application or vice versa.
yet firejail can use xpra to isolate Tor Browser’s access to X
Firejail isn’t actually needed for this. You can just start xpra and start TBB with a custom DISPLAY variable pointing to xpra.
Firejail does make it much easier though and sandboxes xpra.
I figured out how to create seccomp filters with bubblewrap and can maintain sandboxes if needed. It isn’t actually that complicated.
@Vincent43 thinks “no” (my summary of his opinion).
@Vincent43 closed this ticket . Therefore has write access to firejail upstream github repository. This makes the statement more authoritative.
Details here:
I take this back actually. Just having firejail installed worsens the security of your system due to it being setuid root. I think Whonix should take more of an effort to move away from firejail. It has far too large attack surface and is recommended against by many security experts. For example just look at oss-sec: Re: Re: Firejail local root exploit where a guy found numerous security vulnerabilities pretty easily or look at the CVEs.
Were any of these CVE’s related to it being a setuid?
bubblewrap is also setuid.
(says GitHub - containers/bubblewrap: Low-level unprivileged sandboxing tool used by Flatpak and similar projects)
Providing references has a likelihood to convince me.
Not all CVEs are equal. How many or which CVEs would have resulted in a user worse off than not using firejail? Is that a productive question to ask? There could be two types of security bugs:
Bugs of type A) are awful and reason to not use firejail. Bugs of type B) are bad too, but not a reason to discourage firejail.
What about apparmor CVEs?
CVEdetails.com custom Google site search
Or bubblewrap CVEs?
CVEdetails.com custom Google site search
Also I am not sure that level of maintenance in Whonix is possible. There would be a lot of other packages to be reviewed for too many CVEs. Let alone dependencies. Also another factor “that package is in Debian but not well maintained in Debian” (outdated release for years, while upstream version moved forward).
All privilege escalations were as it allows any user to run it with root privileges and exploit those vulnerabilities to gain root.
Bubblewrap has far less attack surface so it being setuid isn’t as much of a problem. For example, using sloccount you can see that bubblewrap only has 3,738 lines of code while firejail has 53,286 lines of code which is a considerable increase in attack surface. Firejail is around 14 times larger.
Another example of bubblewrap’s reduced attack surface is it not even interfacing with raw syscalls for seccomp filters due to it being too complicated Easy seccomp · Issue #317 · containers/bubblewrap · GitHub (you need to create your own filters with seccomp_export_bpf).
Bubblewrap is also only setuid if the OS doesn’t support unprivileged user namespaces which Debian disables by default.
Here are a few examples.
Daniel Micay:
DanielMicay comments on OS Security: iOS vs GrapheneOS vs stock Android
They generally don’t really work as meaningful sandboxes and Firejail specifically is extremely problematic and I would say it substantially reduces the security of the system by acting as a massive privilege escalation hole.
https://lists.archlinux.org/pipermail/arch-general/2017-February/043066.html
A junk, insecure application is not a reason to greatly reduce kernel security for everyone.
Simon McVittie (Debian, bubblewrap, dbus, flatpak maintainer):
Can ease of use be closer to that of firejail? · Issue #266 · containers/bubblewrap · GitHub
(And, yes, I’m aware that Firejail is both complex and setuid root. I think that’s an inadvisable design, and a significant security risk: compare Firejail Project Firejail : Security vulnerabilities, CVEs with Projectatomic Bubblewrap : Security vulnerabilities, CVEs)
7 of them were privilege escalations which just having the binary on your system allowed an attacker to exploit.
Bubblewrap:
Projectatomic Bubblewrap : Security vulnerabilities, CVEs)
AppArmor:
None of these vulnerabilities were privilege escalations.
Not every single package has to be reviewed. High risk applications meant for security with large attack surface and are installed setuid such as firejail do.
Firejail actually has 34,175 LOC, not 53,286. I checked the whole git repo the first time instead of just src/. It’s still a lot of attack surface regardless.
@madaidan Are you saying you can accomplish everything Firejail can with Bubblewrap, including auto sandboxing of programs but in a safer way?
Your wariness of it being setuid just makes me want to give up any sanboxing mechanism that relies on Linux namespaces that have been a notorious privilege escalation path.
For argument’s sake, lines of code and CVEs are not a good metric in my book unless experts have given both the same amount of attention. One can have less CVEs becuase simply no one cared to look at it enough. There are many secure large applications and small ones with Swiss cheese security.
However arguments from people like Micay are worth paying attention to. Argument from authority is not that great, but it’s the best we have at this point.
Mostly yes. Some niche features probably can’t be replicated but all important features are easily replicated.
Firejail’s auto sandboxing of programs just uses /usr/local/bin/ so firejail is the first in $PATH. It’s easy to do the same with bubblewrap.
I do this for some programs in my own personal project e.g. Obscurix/airootfs/usr/local/bin/eog at master · Obscurix/Obscurix · GitHub
Do you mean namespaces are frequently used for priv esc? It’s only really unprivileged user namespaces that do that.
Bubblewrap doesn’t expose much attack surface when using namespaces e.g. its net namespaces don’t expose any netfilter code like it normally does.
I agree CVEs aren’t a reliable way of measuring a program’s security but they can be useful when there’s a bunch of dangerous and easily exploitable CVEs in a semi-niche project like firejail.
Well if any program makes use of them then perhaps it’s better to stay away this post you linked to is pretty scary:
https://lists.archlinux.org/pipermail/arch-general/2017-February/043066.html
Will it be easy to transfer files I want t keep out of bubblewrap sandboxes?
No need to be worried. Debian disables unprivileged use of user namespaces by default debian/patches/debian/add-sysctl-to-disallow-unprivileged-CLONE_NEWUSER-by-default.patch · master · Debian kernel team / linux · GitLab
Some other distros do the same.
Also, don’t get confused between “namespaces” and “user namespaces”. Namespaces are great for sandboxing. They can isolate certain resources e.g. a net namespace can isolate the entire network stack from a program. These should only be accessible by root though which is why many sandboxing programs are setuid.
User namespaces isolate user accounts and allows you to use any namespace unprivileged which is a bad idea as a net namespace for example gives access to a bunch of netfilter administration code (which is normally only accessible by root) which has led to many priv escs.
Bubblewrap makes it fine to use namespaces unprivileged as it doesn’t expose much attack surface as explained above.
Yes. Just mount whatever directory you want to transfer files to. e.g. if you want to transfer files to /home/user/Downloads then just add --bind /home/user/Downloads /home/user/Downloads.
@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.