mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #2947] libpostexecseccomp.so in /run/firejail/lib/libpostexecseccomp.so apparmor issue #1841
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#1841
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
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.dwould help?abstractions/base.das per https://gitlab.com/apparmor/apparmor/issues/50@Vincent43 commented on GitHub (Sep 7, 2019):
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.
@smitsohu commented on GitHub (Sep 18, 2019):
Thanks for pointing to this
abstractions/base.dthing!Though probably (and unfortunately) it will take a while to arrive in the mainstream distributions.
@adrelanos commented on GitHub (Sep 22, 2019):
@Vincent43
Would be good to have either a technical explanation, examples and/or authoritative statement on that.
@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-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 commented on GitHub (Sep 22, 2019):
I try to reply all questions from first post:
Yes, it's bind-mounted there from
/usr/lib/firejailand needed for firejail to work.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.
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 commented on GitHub (Oct 9, 2019):
Closing as questions were answered. Feel free to ask new ones if something is still unclear.