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.
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.
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.