mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #1487] Firefox + Firejail + AppArmor (+ encrypted home directory) seem not to work together #994
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#994
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 @Hocuri on GitHub (Aug 21, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1487
If I call Firefox with
firejail firefoxFirefox will create a new profile instead of using the existing one. After I calledfirejail firefox3 times there are 4 *.profile folders in.mozilla/firefox(the old one plus 3 newly created folders)I know that this can happen if there is no reading access to ~/.mozilla/firefox/profiles.ini which stores the current profile but on the other hand Firefox stores the name of the created profile to it so it does have writing access to it.
I think that this can also happen if the profile is not found where it was expected but I do not know why this should be.
If I add the --noprofile option there is the same behavior but additionally Firefox's Import Wizard is shown (it asks me if I want to import the settings from another browser).
I am running Linux Mint 18.2 Xfce and Firejail 0.9.38.10-0ubuntu0.16.04.1 but in a virtual box with Linux Mint everything is fine, so it seems to have nothing to do with Linux Mint.
Could somebody please help me?
@chiraag-nataraj commented on GitHub (Aug 22, 2017):
Are you using the default profile?
@Hocuri commented on GitHub (Aug 23, 2017):
I do not know if you mean Firefox' or Firejail's profile, but in each case the answer is yes (I reinstalled Firejail with
apt purge firejail && apt install firejailand the behavior was still the same).@SkewedZeppelin commented on GitHub (Aug 23, 2017):
@Hocceruser What is the output of
firejail firefoxand offirefoxlike the first 20 lines of each?@Hocuri commented on GitHub (Aug 23, 2017):
I know what the problem is: I have AppArmor installed on my system. After disabling AppArmor for Firefox everything is fine.
Has someone an idea how to solve this and use the two of them together?
I already added a line
/run/firejail/mnt/fslogger r,to /etc/apparmor.d/local/usr.bin.firefox but it did not help.With Firefox+Apparmor+Firejail:
tail -F /var/log/syslog | grep apparmor
(I have also encrypted my home directory and for some reason Firefox is trying to do something to do with the ENCRYPTED files but why should it be allowed to do this???.)
And the output:
With Firefox+Apparmor: (When everything works fine)
tail -F /var/log/syslog | grep apparmor
Output:
shm_open() failed: Datei oder Verzeichnis nicht gefundenWith Firefox+Firejail: (everything works fine as well)
Output:
@curiosity-seeker commented on GitHub (Aug 26, 2017):
I haven't used AppArmor for a while as I'm on Fedora now but the following should work:
sudo aa-complain /etc/apparmor.d/usr.bin.firefoxsudo aa-logprofThis will open an interactive dialogue in which the necessary rules are presented.
Important: You might need to repeat step 2 several times until all necessary rules are caught!
/etc/apparmor.d/usr.bin.firefoxif you approve them. The problem is that this file will be overwritten whenever AppArmor gets an update. Hence, you should rather manually add those new rules to/etc/apparmor.d/local/usr.bin.firefox.If everything is okay, you should execute
sudo aa-enforce /etc/apparmor.d/usr.bin.firefox@Hocuri commented on GitHub (Sep 10, 2017):
I found out something myself: The problem is probably not that AppArmor's profile for Firefox does not allow access to the file (so curiosity-seeker's suggestion will not work); the problem is that AppArmor does not recognize the file, probably because the path does not start with a "/". Here is again a part of AppArmor's entry to the syslog:
Here: http://wiki.apparmor.net/index.php/FAQ#Failed_name_lookup_-_disconnected_path it says that this is due to a "lazily unmounted device path opened outside of current namespace".
So it has something to do with Firejail's namespaces. Is there any chance that there can be a patch for that?
@Hocuri commented on GitHub (Sep 10, 2017):
I am not entirely sure if the encrypted home directory has something to do with the problem but in a VM without encrypted home Firefox + Firejail + AppArmor worked perfektly.
@curiosity-seeker commented on GitHub (Sep 10, 2017):
Okay, I remember that I had a similar problem when I was still using AppArmor. Adding
flags=(attach_disconnected)to the affected AppArmor profile solved the problem. More details here.
@Hocuri commented on GitHub (Sep 11, 2017):
Yes, this solved problem, thank you very, very much.
But what can we do so than other people do not encounter the same problem? Supervise the syslog (/var/log/syslog) when starting a program the first time and print a warning if there are is an entry like this?
Or directly ask if the user wishes Firejail to add
flags=(attach_disconnected)to the concerning AppArmor Profile?@Hocuri commented on GitHub (Sep 16, 2017):
@netblue30 What do you think?
@Hocuri commented on GitHub (Sep 18, 2017):
I've got another idea: If AppArmor is installed (or maybe only if it wrote something "suspicious" to the syslog) the user is warned and relegated to some web site or man page where the problems and the solutions are explained.
BTW, does anybody know if these problems also appear with Firejail+SELinux? Probably not because SELinux uses file labels instead of path names, or am I mistaken?
@curiosity-seeker commented on GitHub (Sep 19, 2017):
No, there are no problems with SELinux - perhaps because Firefox is not confined on Fedora/Red Hat systems (although it is on Gentoo which I've never tried).
@ghost commented on GitHub (Sep 24, 2017):
@Hocceruser I think the problem is that you are trying to use appamor (from kernelspace) and firejail (from userspace) to do the same thing (Mandatory access control) which is redundant. It's like using two firewalls or two antivirs which would fight each other.
There is no point to use both to block access to same files. Firejail has nice apparmor support by invoking
firejail --apparmorwhich is used to do things firejail isn't capable to do by itself but not to double the work it already do.My recommendation is to choose one of those tools to confine specific app, i.e. you can use firejail to confine desktop apps (combining with apparmor support switch) and apparmor to confine system daemeons.
Weakening apparmor security only to make it do same things which firejail already do doesn't make sense from security perspective.
@Hocuri commented on GitHub (Sep 24, 2017):
You are probably right, I'll disable AppArmor for Firefox by the next opportunity.
But when Firejail discovers that the concerning program is confined with AppArmor, it should at least print a warning that Firejail does not work together with AppArmor very well and that it is redundant to use the two of them together anyway .
There is a very small security enhancement because AppArmor's profiles are a bit more granular than Firejail's (and I weakened only AppArmor's Firefox profile, so it will not decrease the security in any way) but still it is not worth it by very far.