The Tor Browser firejail profile is managed by the firejail team upstream. They would hopefully fix any problems quickly.
There’s a gap between issue being identified, and fixed. On top of that, the firejail-profile package from packages.debian.org is only upgraded during Debian release upgrades, such as from Debian buster to Debian bullseye.
1 Like
Debian backports serious bug fixes. They’d likely fix any seriously broken profile before release upgrades.
Checked Debian changelog. I haven’t seen any upgrades of package apparmor-profiles or firejail-profiles ever that were uploaded to any other Debian suite other than unstable first, i.e. require a release upgrade until these flow into testing and the next stable release of Whonix.
Debian doesn’t ship Tor Browser. So is not responsible for that application which is upgraded outside of its repository.
Also very much dependent on the Debian maintainer. A lot variables. Too many.
1 Like
But how will a remote site be able to differentiate between performance loss caused by an allocator vs one attributable to just running TBB on a crappy computer?
1 Like
My goal is to fins out:
*If stacking Firejail and Apparmor us any better than just using firejail for TBB
*Find out who maintains the most current profile and see if we can cooridante with TPO to provide an officially maintained/unit tested version from their repos.
1 Like
Speculation: Could be because an allocator might influence non-linearly some feature more than another while a crappy computer influences it in a more linear way.
firejail man page talks a lot about apparmor.
Upstream firejail has a few Tor Browser related issues (might already be most if not all closed by now). Looks like upstream is quick to fix such. Looks like with apparmor upstream gives apparmor but leaves applications to application developers while firejail upstream provides a ton of firejail profiles. I might be wrong about this.
1 Like
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.
2 Likes
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.
2 Likes
I figured out how to create seccomp filters with bubblewrap and can maintain sandboxes if needed. It isn’t actually that complicated.
2 Likes
@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:
1 Like
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:
- A) those bugs when a compromised, firejial confined application can abuse firejail to gain root or kernel access
- B) those bugs who “only” render firejial useless, allow a compromised, confined application to act as if it would not be running under firejail.
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.
- How many CVEs of type A) are too much?
- How many CVEs of type B) are too much?
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).
2 Likes
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.
1 Like
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.
2 Likes
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.
1 Like
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?
1 Like
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.
1 Like