Unfortunately everyone.
1 Like
Please experiment with this in Whonix 15.
sudo apt-get install firejail-profiles
(Whonix VirtualBox 15.0.0.0.7 - Debian buster based - Testers Wanted!)
Let me know if this breaks anything.
(Related to ⚓ T869 Install Firejail by default inside Whonix)
2 Likes
using this command:
firejail --debug --seccomp torbrowser
it is working!
1 Like
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.
Related:
1 Like
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.
1 Like
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.
1 Like
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.
2 Likes
Bubblewrap doesn’t have direct support for X sandboxing but it can still be done anyway by just doing
bwrap --dev-bind / / --unshare-all /usr/bin/Xephyr
Then just run whatever programs you want in there.
1 Like
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.
1 Like
I dont have it, it was in Tor-Talk list.
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.
1 Like
Firejail does have more features than bubblewrap but a lot of these aren’t needed and would just be unneeded attack surface.
Bubblewrap would be easier to maintain than Firejail. It’d be easier to maintain a simple command than a lengthy profile.
1 Like
apparmor vs firejail
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.
2 Likes
In effect you would need to weaken both firejail and apparmor profiles which makes the sense of running them both questionable.
Firejail profiles don’t need to be weakened and allowing access to a few libraries in /run/firejail doesn’t seem to be weakening AppArmor much.
1 Like
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-defaultgeneric 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/firejailand 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.
2 Likes
1 Like
As far as I understand, that’s a local privilege escalation vulnerability.
There are two things that can go wrong with (an application similar to or) firejail.
- local privilege escalation vulnerabilities
- sandbox escape vulnerabilities
If I understand this right… The prerequisite to exploit above issue is local user compromise. Applications running inside a firejail sandbox couldn’t use this.
1 Like
So I assume you’re saying this is a fixable bug and not an inherent flaw with the way firejail or Linux works.
1 Like
No, I didn’t comment on that at all.
Generally, I am wondering if how a vulnerability effects the threat model can be better understood, documented. Thereby was attempting here to classify this issue.
Generally, the approach some vulnerability -> stay away from that application would be a falacy. But I think that is the take away message that many users would take from this.
For example,
- sha-2 is vulnerable to length extension attack but at time of writing I couldn’t find any hash collision. For example Bitcoin uses sha-2 but I haven’t found any claims that it gets any less secure because of any sha-2 length extension attack, that because of that anyone could generate any Bitcoin without mining them as intended.
- sha-2 has some vulnerability → Bitcoin uses sha-2 → therefore Bitcoin is also vulnerable would be a wrong conclusion.
- this flatpak security discussion: FlatPak as a Software Source / flathub as a source of software - #23 by Patrick
1 Like