[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [CONTRIBUTE] [DONATE]

firejail / seccomp / More Options for Program Containment

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 https://phabricator.whonix.org/T869#18198)

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:

https://wiki.archlinux.org/index.php/Bubblewrap

https://jlk.fjfi.cvut.cz/arch/manpages/man/bwrap.1

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

Could anybody provide any feedback on http://nsjail.com/ ? This is probably a related tool.

2 Likes

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

Quote @Vincent43

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

2 Likes

2 posts were split to a new topic: How to run Tor Browser with Firejail?

https://unparalleled.eu/blog/2021/20210208-rigged-race-against-firejail-for-local-root/

https://unparalleled.eu/publications/2021/advisory-unpar-2021-0.txt

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
1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]