[GH-ISSUE #2947] libpostexecseccomp.so in /run/firejail/lib/libpostexecseccomp.so apparmor issue #1841

Closed
opened 2026-05-05 08:30:35 -06:00 by gitea-mirror · 6 comments
Owner

Originally created by @adrelanos on GitHub (Sep 7, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2947

Tor Browser 8.5.5 with firejail and https://github.com/Whonix/apparmor-profile-torbrowser

Sep 07 03:25:54 host kernel: audit: type=1400 audit(1567826754.074:42): apparmor="DENIED" operation="open" profile="/**/*-browser/Browser/firefox" name="/run/firejail/lib/libpostexecseccomp.so" pid=7879 comm="firefox.real" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

Does libpostexecseccomp.so really have to reside in /run/firejail/lib/libpostexecseccomp.so?

Ideally firejail would not cause apparmor issues.

Maybe the (upcoming deepening on your apparmor version) abstractions/base.d would help?

abstractions/base.d as per https://gitlab.com/apparmor/apparmor/issues/50

Originally created by @adrelanos on GitHub (Sep 7, 2019). Original GitHub issue: https://github.com/netblue30/firejail/issues/2947 Tor Browser 8.5.5 with firejail and https://github.com/Whonix/apparmor-profile-torbrowser > Sep 07 03:25:54 host kernel: audit: type=1400 audit(1567826754.074:42): apparmor="DENIED" operation="open" profile="/**/*-browser/Browser/firefox" name="/run/firejail/lib/libpostexecseccomp.so" pid=7879 comm="firefox.real" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 Does libpostexecseccomp.so really have to reside in `/run/firejail/lib/libpostexecseccomp.so`? Ideally firejail would not cause apparmor issues. Maybe the (upcoming deepening on your apparmor version) `abstractions/base.d` would help? `abstractions/base.d` as per https://gitlab.com/apparmor/apparmor/issues/50
gitea-mirror 2026-05-05 08:30:35 -06:00
Author
Owner

@Vincent43 commented on GitHub (Sep 7, 2019):

Ideally firejail would not cause apparmor issues.

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.

<!-- gh-comment-id:529116717 --> @Vincent43 commented on GitHub (Sep 7, 2019): > Ideally firejail would not cause apparmor issues. 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.
Author
Owner

@smitsohu commented on GitHub (Sep 18, 2019):

Thanks for pointing to this abstractions/base.d thing!

Though probably (and unfortunately) it will take a while to arrive in the mainstream distributions.

<!-- gh-comment-id:532834838 --> @smitsohu commented on GitHub (Sep 18, 2019): Thanks for pointing to this `abstractions/base.d` thing! Though probably (and unfortunately) it will take a while to arrive in the mainstream distributions.
Author
Owner

@adrelanos commented on GitHub (Sep 22, 2019):

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

Would be good to have either a technical explanation, examples and/or authoritative statement on that.

<!-- gh-comment-id:533852549 --> @adrelanos commented on GitHub (Sep 22, 2019): @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. Would be good to have either a technical explanation, examples and/or authoritative statement on that.
Author
Owner

@Vincent43 commented on GitHub (Sep 22, 2019):

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.

<!-- gh-comment-id:533869245 --> @Vincent43 commented on GitHub (Sep 22, 2019): 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.
Author
Owner

@Vincent43 commented on GitHub (Sep 22, 2019):

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

<!-- gh-comment-id:533895376 --> @Vincent43 commented on GitHub (Sep 22, 2019): 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 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 its 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.
Author
Owner

@Vincent43 commented on GitHub (Oct 9, 2019):

Closing as questions were answered. Feel free to ask new ones if something is still unclear.

<!-- gh-comment-id:540179345 --> @Vincent43 commented on GitHub (Oct 9, 2019): Closing as questions were answered. Feel free to ask new ones if something is still unclear.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#1841
No description provided.