I don’t think we can guarantee zero regressions, but anecdotally I have yet to find a program that doesn’t work with firejail.
From the ParrotOS thread, it appears that what happens is Firejail has a script which can automatically compare installed system binaries and reinstall symlinks as packages are reinstalled. Parrot runs this script (which I haven’t seen but haven’t really dug for yet) every time a package is installed via a post-installation step. This itself could be dangerous as perhaps a user is unaware that firejail is not reinstalled in front of a package reinstall, or perhaps they install a package that is not protected by default firejail profiles and also not ParrotOS firejail profiles and expect it to be automatically applied. User education will always solve problems where technology is lacking. We should make the user aware that firejail is in play on the system regardless of how seamless we can make the integration as they may want to review firejail and the available integrated profiles for themselves.
That all said, I am still learning and still educating myself on firejail and the current state of Whonix development itself. If I could send a pull request that would implement firejail as a default package on a meta package, and then create a post-install hook to implement firejail profile reinstallation, and then implement specific and tight firejail profiles, that would still not alleviate all of the potential problems. Again, user education is key, and I’ve noticed this mentioned a couple of times in the Whonix wiki and could not agree more.
That’s just my $.02 on the matter, for what that’s worth right now. Still learning.
systemctl --no-pager --no-block status tb-updater-first-boot.service.
systemctl output:
Failed to connect to bus: Permission denied
To see this for yourself, you could try:
Start Menu -> Applications -> System -> Terminal
Then run:
systemctl --no-pager --no-block status tb-updater-first-boot.service
Installing /run/firejail/mnt/seccomp.protocol seccomp filter
[ERROR] [torbrowser] Failed to start Tor Browser!
Failed to run:
systemctl --no-pager --no-block status tb-updater-first-boot.service.
systemctl output:
Failed to connect to bus: Permission denied
To see this for yourself, you could try: Start Menu -> Applications -> System -> Terminal
Then run:
systemctl --no-pager --no-block status tb-updater-first-boot.service
Sandbox monitor: waitpid 6 retval 6 status 1024
Not related to Firejail but I would like to suggest bubblewrap as an alternative sandboxing program. It uses Linux namespaces to isolate programs and doesn’t require profiles like Firejail does so it should be easier to maintain. It’s used as a command instead. e.g.
bwrap --dev-bind / / --unshare-all foo
This will use all namespaces available to sandbox foo.
It can also be used to remove network access for programs that don’t need it with the --unshare-net option.
It’s in the Debian repos too.
It’s not that complicated either.
Another advantage to Firejail is that it has a very small attack surface unlike Firejail which has a massive attack surface. This makes it much more likely to contain less vulnerabilites.
Check latest news on CentOS and Ubuntu removing Bubblewrap (a sandboxing tech used by Flatpak) support.
Warning: Unlike when using a separate user and a separate log-in
session, 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.
Link? I can only find articles of them removing bubblewrap’s GNOME thumbnail sandbox because they haven’t audited it yet.
Warning: Unlike when using a separate user and a separate log-in
session, 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.
That is the same for every other sandbox, including Firejail. The only way to protect those is to use a virtual machine.
Both bubblewrap and firejail make use of Linux namespaces that can allow kernel exploits. The difference is Firejail allows isolation of GUI apps with xpra while bubblewrap offers no such feature AFAICT.
I was looking at it yesterday. It looks interesting but I’m inclined not to trust anything made by Google. It also doesn’t seem to be in the Debian repos.
Otherwise, it looks good although a bit complicated. It looks similar to Firejail and Bubblewrap. It seems to have a “profile” for Firefox that could probably be adapted for the Tor Browser easily.
True, so no point to use another alternative and as hulahoop said there is extra feature in firejail not in bubblewrap. also profiles i see it better so we can customize it for each app easily.
I would say that firejail regularly causes issues for apps confined with standalone AppArmor profiles and the other way around. In essence they are blocking each other from functioning. In effect you would need to weaken both firejail and apparmor profiles which makes the sense of running them both questionable.
Interesting. Not yet sure that should be believed. There isn’t much technical explanation. And I don’t know it can be taken as an authoritative statement.
There was technical elaboration in the same ticket.
Vincent43:
AppArmor sandbox is path based and uses whitelist approach by default. Firejail sandbox is also path based and uses blacklist approach by default. It also uses namesapces and rewrites some paths in sandbox which cause denials in AppArmor as you can see. The only case supported by firejail related to AppArmor is using firejail-default generic profile which shouldn’t cause issues. Users who want to use app specific profiles with firejail are on their own as there is nothing firejail can do to help them. I can’t and won’t authoritatively force you on anything but avoiding using app specific AppArmor profile with firejail is my best advice.
Vincent43:
I try to reply all questions from first post:
Does libpostexecseccomp.so really have to reside in /run/firejail/lib/libpostexecseccomp.so?
Yes, it’s bind-mounted there from /usr/lib/firejail and needed there for firejail to work.
Ideally firejail would not cause apparmor issues.
This issue is caused by your custom apparmor profile not allowing firejail creating its own sandbox. There are unlimited ways for apparmor to block firejail from functioning and firejail can really prevent this happening on your own.
Maybe the (upcoming deepening on your apparmor version) abstractions/base.d would help?
In this case firejail’s apparmor integration isn’t used at all so all apparmor tweaks belong to your custom profile.
I hope this help understanding the problem better.
@Vincent43 closed this ticket. Therefore has write access to firejail upstream github repository. This makes the statement more authoritative.