There was some discussion about utilizing Apparmor in another recent thread, but it would be OT continuing it so I've started this one. Out of curiosity I wanted to see if I could create a decent profile to harden Firefox v69.0.3 further than I've already got it with Firejail, uBlockO, NoScript (just for XSS & click-jacking protection) and modifications in preferences. I've generated one that took me well over 30 minutes using the Scan option after profiling with "AA-logprof" with the majority of my rules edited using the [N]New option. There has been some further profiling and rule modifying using the "aa-logprof" option as well. BTW, hardening FF with Apparmor is probably security-overkill when it's already fortified with Firejail and other hardening measures, but I couldn't help myself to try it. By no means am I expert with Apparmor, only knowing enough to generate working profiles and check for and modify when there are problems. One little test I tried was to attempt to install an add-on from mozilla.org and Apparmor stopped it dead when I attempted to "Add" it. I'm encountering resistance as I'm typing this, attempting to upload an image, so Apparmor is certainly doing its job! I had to run "aa-logprof" then scan and update the profile in order to upload the image, which shows the result of the test installation of the add-on. I don't really want to share my profile, because I don't want to deal with all the potential questions and criticisms about it. EDIT Btw, I think at least some of the profiles provided in the repositories are either too weak to effectively harden the application or too incomplete that they break functionality of the program they’re meant for
Have you also tried the Firejail apparmor profile? That's worked ok for me for some sites, and I tend to have different Firejail private homes for different instance of FF. I'm also fond of Multi Account Containers.
Hi DeBotie, no I haven't used the firejail-default profile. The one I created for Firefox is a 187 lines long. Last night I had to add a couple rules in order to play a Netflix movie. As the screenshot above implies, it won't allow any other FF Add-ons, other than the ones I've already got installed. A rule for uBlockO is as follows: Code: /home/*/.mozilla/firefox/*/extensions/uBlock*.xpi r, BTW, when creating the FF profile, I ran it un-firejailed, otherwise there are conflicts. Of course when it's all done, I run it firejailed along with the apparmor restrictions in place.
Combining custom AA profile & FJ is not recommended unless you're familiar w/ how they all work, not only for problems but that can potentially spoil security. Using seccomp-bpf only was suggested there, but Fx already uses it so the benefit will be limited. As you trust FJ, probably just configure its profile will be better - default FJ profiles are also adjusted to meet as many distro and usage, so there are room to configure too. [EDIT] Sorry if I interpreted your intention wrongly.
On the contrary, I'm seeing more restrictions when combining Apparmor and Firejail, as I've alluded to in my above posts. Remember, I set up the FF profile Unfirejailed, so the restrictions in the AA profile were in no way influenced by Firejail. So far I see this combination as enhancing security, not spoiling it. I will, however, keep an eye on things and dig as deep as I can to unveil any issues if any exist. EDIT One of the members from that discussion you linked to advises he noticed some things ignored that he specifically denied read access to in AA when he ran FJ, so I decided to open my profile and for an experiment comment out the lines: Code: #/home/*/Downloads/* rw, #/home/*/Downloads/bookmarks*.html r, #/home/*/Downloads/my-ubloc*.txt w, well, in all cases I was unable to save my bookmarks, UblockO's settings, nor could I save the ccleaner download. AA blocked them all, and the subsequent logprof I ran proved this. I've attached a screenshot as well. The official FJ documentation even suggests FJ should work fine on top of AA. https://firejail.wordpress.com/documentation-2/basic-usage/
BTW, my latest and current Firefox AA profile is now at 289 lines of text. I studied the initial, earlier profile carefully, and decided to fine tune it to be more granular, and therefore more restrictive than before. I had some difficulties with uBlockO add-on breaking, and also breaking the FF browser functionality when I made a modification to an earlier profile, but with some further aa-logprof scanning and profile modification, all is good now. @142395 and anyone else, for that matter, who wants to assert using AA and FJ in combination will spoil security, please provide evidence as such, and I will be happy to respond with corrective measures. Good luck!
Yes, that's true. However, the Firejail wiki says otherwise. So what the Firejail guys suggest is not really consistent. I had been using AppArmor for a long time but then I switched to distros not supporting it. After returning to Arch Linux I've enabled it again but didn't create my own profiles but rather used the firejail-default profile. Recently I started creating profiles for Firefox and Thunderbird again, and so far I haven't noticed, either, that using both AA and FJ "will spoil security" as you put it. I've only noticed that 2 rules related to FJ were necessary for the Firefox AA profile, namely: Code: /run/firejail/lib/lib*so* mr, owner /run/firejail/mnt/seccomp/seccomp.postexec r, I'm still in an evaluation phase.
Actually, I wasn't the one who stated it would "spoil security" So far, I'm encountering issues with extension rules such as, for example: Code: /home/*/.mozilla/firefox/zvfc9zd3.default/extensions/\{73a6fe31-595d-460b-a920-fcc0f8843232\}.xpi r, This is the extension file for NoScript add-on, although it's happening with a couple of theme extensions as well. The issue is that even though I create the rules using aa-logprof, every other time I use aa-logprof after simply opening and closing FF results in the same entries coming up again and again. I've tried different syntax such as "*" (no quotes) for the specific characters between the curly brackets but nothing works. The extensions at least aren't broken, but I can't understand why the profiling keeps generating these same entries over and over again. This is happening opening FF Unfirejailed, which is how I profiled FF, because profiling it firejailed causes problems. At any rate, using both FJ and AA is definitely making FF incredibly restrictive. The additional security provided by AA seems powerful. Any action from the browser I attempt that isn't covered in the AA profile, is blocked by AA. I guess (hope) that FJ is also restricting accordingly, but no doubt there's overlap. That's a good thing the way I see it. Maybe in the end, I will just run FF in AA only, as others have suggested, but so far in spite of some minor issues, I will continue using both FJ and AA. EDIT I'm also making sure to Reload the profile after every aa-logprof routine. I have also just discovered those .XPI entries that keep repeating, are doing so even if I don't open FF after profiling! Strange, they are being written into the profile but aa-logprof routines continue to display them every time.
@wat0114 I hope you didn't miss the word can & potentially, anyway, I have no evidence and TBH have no interest to assert sth (I mean, defend my view) or persuade sb. One possibility I thought of was, as topimiettinen suggested, FJ uses mount namespace to have a process to have its own view of filesystem, which might make a path to access resources otherwise forbidden by AA. Tho not directly relevant, there was an AA bypass using pivot_root (Bug#1791711). But if you tested (maybe you tested read access too?) carefully and made the profile w/out Firejailed, that will probably be fine. BTW, note "*" does not replace "/". So if you wanna block any read under /downloads/, you need to write /downloads/** r, not /downloads/* r - actually, download/{,**} r is recommended for known bypass (Bug#1794820). I think your problem is caused by * under /home/.
Thanks Yuki, no problem, it's just that I don't want to let other's issues discourage me from forging ahead, especially when I'm seeing mostly positive results with AA combined with FJ. For those problem .XPI extensions, I tried: {*-*-*-*-*\} but that doesn't work. I could glob with something like: *.xpi omitting the brackets, but that is far too permissive for my liking. I have finally just decided to ignore the repeat entries of logprof, as this causes no issues whatsoever. It seems to be possibly a bug in AA, I think. I just keep the exact .XPI path to eliminate over-permissiveness. I have found excellent documentation on AA at this openssuse site
I have found it possible to create separate profiles for: usr.local.bin.firefox, opt.firefox.firefox and opt.firefox.firefox-bin, but then FF will only launch Unfirejailed. To use AA and FJ together, I've so far only made this possible when using the "Inherit" option for both opt.firefox.firefox and opt.firefox.firefox-bin under usr.local.bin.firefox. Hopefully this makes sense.
Is anyone using the firejail-default Apparmor profile? I have it enforced in the Apparmor.d directory, and it shows it as such when I do a AA-status command, but I don't see any firejail-related process being enforced. I run Firefox v70 with its own profile that I created firejailed, and it shows the FF processes enforced but no process(es) from firejail. FF is definitely running under firejail as seen with: Code: $ firejail --list 3924:user::firejail firefox
I'm not explicitly using the firejail-default AppArmor profile but rather automatically if that flag is enabled in a Firejail profile. If you want to use your own AppArmor profile for a specific application and the corresponding Firejail profile contains the apparmor flag, you have to add ignore apparmor to your local Firejail profile for that application (in /etc/firejail or in ~/.config/firejail) or you add a full profile to ~/.config/firejail that does not contain the apparmor flag - otherwise only firejail-default and not your own profile will be used.
I don't have my own firejail profile, only the default firejail profile included. I'm just puzzled why I don't see a particular firejail process being enforced. Thank you for your response. It seems very few of us are using Linux
I must admit that I'm a bit confused As mentioned, the firejail-default AppArmor profile is only used when the apparmor flag in the Firejail profile for the respective application is enabled. Put another way: If you created your own Firefox AppArmor profile but start Firefox with its standard Firejail profile (which contains the apparmor flag in firefox-common.profile), your own AppArmor profile isn't used at all but firejail-default is used instead. But perhaps I misunderstood your remark? Btw.: If you want a more detailed view of your AppArmor profiles you can start aa-status with an option: Code: sudo aa-status --pretty-json Yes, sad enough. And not all of them are using Firejail and/or AppArmor.
No I think you understood fine. The apparmor flag is enabled in the firefox-common.profile and I also did create and enforce my own firefox apparmor profile. I was just expecting to see a firejail process being enforced, but maybe it doesn't work that way. What matters most is that firefox is enforceed by my own custom profile, as well as simultaneously being sandboxed by firejail. Thanks again. That aa-status option is handy.
Hm, I'm not sure that we are in agreement To clarify: If the apparmor flag in the Firefox profile is disabled by adding ignore apparmor, aa-status --pretty-json shows (under processes): Code: "/usr/lib/firefox/firefox": [ { "pid": "13071", "profile": "/usr/lib/firefox/firefox", "status": "enforce" }, { "pid": "13100", "profile": "/usr/lib/firefox/firefox", "status": "enforce" }, { "pid": "13148", "profile": "/usr/lib/firefox/firefox", "status": "enforce" }, { "pid": "13204", "profile": "/usr/lib/firefox/firefox", "status": "enforce" }, { "pid": "13289", "profile": "/usr/lib/firefox/firefox", "status": "enforce" } ], If the apparmor flag is enabled in the Firefox profile, aa-status shows: Code: "/usr/lib/firefox/firefox": [ { "pid": "12655", "profile": "firejail-default", "status": "enforce" }, { "pid": "12684", "profile": "firejail-default", "status": "enforce" }, { "pid": "12730", "profile": "firejail-default", "status": "enforce" }, { "pid": "12791", "profile": "firejail-default", "status": "enforce" }, { "pid": "12873", "profile": "firejail-default", "status": "enforce" } ], See the difference? If you're using the standard Firefox profile in Firejail (where apparmor is enabled) your individual AppArmor profile is not used.
Hmmm...I'm confused I guess. When I launch "aa-status --pretty-json" I get: Code: "processes": { "/opt/firefox/firefox-bin": [ { "pid": "9894", "profile": "/usr/local/bin/firefox", "status": "enforce" }, { "pid": "9938", "profile": "/usr/local/bin/firefox", "status": "enforce" }, { "pid": "9986", "profile": "/usr/local/bin/firefox", "status": "enforce" }, { "pid": "10046", "profile": "/usr/local/bin/firefox", "status": "enforce" } ], "/usr/bin/bash": [ { "pid": "9893", "profile": "/usr/local/bin/firefox", "status": "enforce" } Code: }, "profiles": { "/usr/bin/irssi": "complain", "/usr/bin/man": "enforce", "/usr/bin/pidgin": "enforce", "/usr/bin/pidgin//sanitized_helper": "enforce", "/usr/bin/totem": "enforce", "/usr/bin/totem-audio-preview": "enforce", "/usr/bin/totem-video-thumbnailer": "enforce", "/usr/bin/totem//sanitized_helper": "enforce", "/usr/lib/cups/backend/cups-pdf": "enforce", "/usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session": "enforce", "/usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session//chromium": "enforce", "/usr/local/bin/firefox": "enforce", "/usr/sbin/apt-cacher-ng": "enforce", "/usr/sbin/cups-browsed": "enforce", "/usr/sbin/cupsd": "enforce", "/usr/sbin/cupsd//third_party": "enforce", "/usr/sbin/dnsmasq": "complain", "/usr/sbin/dnsmasq//libvirt_leaseshelper": "complain", "/usr/sbin/haveged": "enforce", "/usr/sbin/ntpd": "enforce", "avahi-daemon": "complain", "firejail-default": "enforce", "identd": "complain", "klogd": "complain", "man_filter": "enforce", "man_groff": "enforce", "mdnsd": "complain", "nmbd": "complain", "nscd": "complain", "nvidia_modprobe": "enforce", "nvidia_modprobe//kmod": "enforce", "ping": "complain", "smbd": "complain", "smbldap-useradd": "complain", "smbldap-useradd///etc/init.d/nscd": "complain", "syslog-ng": "complain", "syslogd": "complain", "traceroute": "complain" }, I better explain exactly what I am doing: I'm using the firejail firefox profile firefox.profile, which also utilizes firefox-common profile I created my own firefox apparmor profile which is called usr.local.bin.firefox - it is enforced in apparmor I am using the firejail-default apparmor profile - it is enforced in apparmor I don't have any disabled flag checked for apparmor anywhere when I launch that aa-status --pretty-json command, it shows above the firefox processes enforced by my usr.local.bin.firefox apparmor profile It also shows the usr.local.bin.firefox and firejail-default profiles are enforced That's all I can really tell you. In short, my usr.local.bin.firefox profile is enforced, which enforces Firefox processes, and the firejail-default profile seems to be also enforced. Firefox also seems to be confined in firejail sandbox when it's launched, as the firejail --tree shows this.
@wat0114 : Okay, I see what you're doing. You created an AA profile for /usr/local/bin/firefox which is a symlink pointing to /usr/bin/firejail. I've never tried that and I would be interested about the rules therein referencing firejail or, say, /run/firejail/whatever ... That said, I think that what you're doing is problematic: If another application starts Firefox as a helper application by using its full path - i.e. /usr/bin/firefox - it would not be confined by AppArmor (nor by Firejail). You know, there is one objection against Firejail - that it can easily be circumvented by executing the respective application using its full path so that the symlink to firejail does not come into effect. While that is true, I think that this arguement is mainly theoretical: 1. That malware is able to break out of the sandbox is very unlikely - and helper applications would be started inside the sandbox, hence, its boundaries would apply to them as well. 2. It's possible that the full paths for helper applications which are normally started sandboxed are used - this is, e.g., the case in krusader. 3. The user could download an untrustworthy application/script from some website and execute it (and it could, of course, also use the full path to some applications in order to start them unsandboxed). Solution: always use trustworthy packages from the official repositories. If it comes to AppArmor the thing is that on my Arch Linux system /usr/bin/firefox is the following script: Code: #!/bin/sh exec /usr/lib/firefox/firefox "$@" Which means: regardless if Firefox is executed as /usr/local/bin/firefox or /usr/bin/firefox - ultimately always /usr/lib/firefox/firefox is started. And if that executable is confined by AppArmor, it cannot be bypassed. The official profile confines /usr/bin/firefox which has the same effect. In your Linux MX system it seems that /opt/firefox/firefox-bin is executed instead so this is probably the executable started by /usr/bin/firefox. That's the one that should be confined by AppArmor. To recap: If you create an AppArmor profile for /usr/local/bin/firefox but Firefox is started with /usr/bin/firefox by another application it will not be confined by Firejail nor by AppArmor. You can easily test it yourself by executing /usr/bin/firefox in the console. It should not show up in firejail --list nor in aa-status.
Hi summerheat, I did not want to settle on creating an apparmor profile this way, but any other way I've tried where I did a Px on, say, opt.firefox.firefox-bin, results in not being able to use firejail as well with firefox, so I simply inherited everything when generating the profile, which results in one profile: usr.local.bin.firefox. However, I just a few minutes ago re-generated apparmor profiles for Firefox and now I have two: usr.local.bin.firefox and opt.firefox.firefox-bin. I did a Px on opt.firefox.firefox-bin. This works, but not in combination with firejail. I'm no expert with apparmor as you can tell, but I am leaning toward simply using apparmor only for firefox, unless or until I can figure out how to run properly sanitized profiles with firejail. EDIT: btw, assuming firefox is running in apparmor confinement, would it also not be difficult for malware to execute, given the restrictions that the apparmor profile, assuming one has created a fairly strict one, is placing on the browser? All the rules in the profile basically tell the browser exactly how it can function, and no more. EDIT 2: here is the beginning of the usr.local.bin.firefox: Code: # Last Modified: Thu Oct 31 11:50:28 2019 #include <tunables/global> /usr/local/bin/firefox { #include <abstractions/base> #include <abstractions/bash> #include <abstractions/lightdm> #include <abstractions/totem> #include <abstractions/ubuntu-konsole> /opt/firefox/firefox-bin Px, /proc/cpuinfo r, /proc/filesystems r, /proc/sys/crypto/fips_enabled r, owner "/home/*/.mozilla/firefox/Crash Reports/InstallTime*" r, owner /**/ rw, owner /home/*/.ICEauthority r,......continues you can see a few lines into it: /opt/firefox/firefox-bin Px, so I have sanitized (I think) the child process of Firefox
Absolutely, I agree. Yes, that's the executable that should be confined by AppArmor. If you have that I don't think that an AA profile for /usr/local/bin/firefox serves any purpose as /opt/firefox/firefox-bin is always executed and Firefox is therefore confined anyhow.
Thank you confirming, summerheat For fun and because i can't help myself. I re-did the firefox profile, making it a little more strict than before. I've also tested launching firefox from terminal as: Code: /usr/bin/firefox[/ and from changing to directory: Code: /usr/bin and launching it from there and in both cases firefox process opt.bin.firefox-bin is enforced by aparmor.
I think in the first case you meant: /usr/local/bin/firefox, didn't you? If so it confirms what we were discussing. And regarding what you wrote in your previous post: It does not work for you in combination with Firejail?
No, I opened it as /usr/bin/firefox. I did also just try /usr/local/bin/fireox and apparmor still confines it. I'm still learning Linux No, firejail won't work with this type of profile. Maybe I need to somehow sscrap the small profile which you earlier suggested I don't need: Code: Last Modified: Fri Nov 1 09:27:16 2019 #include <tunables/global> /usr/local/bin/firefox { #include <abstractions/base> #include <abstractions/bash> #include <abstractions/consoles> #include <abstractions/lightdm> #include <abstractions/totem> #include <abstractions/ubuntu-konsole> /home/*/Documents/libreoffice.profile r, /home/*/Documents/loffice.profile r, /opt/firefox/firefox Px, } /usr/local/bin/firerox always comes up when I use aa-genprof, so I simply did the Px for /opt/firefox/firefox, which has a profile: Code: # Last Modified: Fri Nov 1 06:48:27 2019 #include <tunables/global> /opt/firefox/firefox { #include <abstractions/base> /opt/firefox/firefox mr, /opt/firefox/firefox-bin Px, } Maybe I've complicated things I figured I had to do something with these entries, or can I simply ignore them and only profile /opt/firefox/firefox-bin ? Could the two small profiles above be interfering with firejail? BTW, the opt.firefox.firefox-bin profile is 385 lines long. I could have done some serious reducing of it with liberal use of wildcards, but I want a tight, restrictive profile.
LOL...I may have made some progress. I disabled the usr.local.bin.firefox profile, and firefox still launches from the shortcut under apparmor's constraints. So obviously I don't require that profile, which of course you suggested earlier I now only have the opt.firefox.firefox and opt.firefox.firefox-bin profiles. The only somewhat bad news still is firefox won't launch with firejail. There is something I will try, however, after I post this. EDIT: the experiments I tried didn't work, but no big deal. I'm happy with enforcing Firefox with Apparmor only. For the record, I didn't enable any of the abstractions or tunables, which I guess would have made profiling easier, but also, from what I saw, probably less restrictive too.
