v24.04 snap.firefox.firefox apparmor profile INSECURE

[vbgf3]

Hi,

I find the apparmor profile snap.firefox.firefox insecure in that it allows read access to the whole drive and the entire home directory. The @{HOME}/Documents directory should be denied because it houses private and secret documents. Allowing reads from the root down allows attackers to load any library she needs - very dangerous should there be a vulnerability in firefox.. Apparmor profiles' purpose is to confine access and only allow what is absolutely required by each app, or else it won't be functioning as a security layer.

For example :

  # Allow read-access to / for navigating to other parts of the filesystem.
   / r,

  # Allow read-access on /home/ for navigating to other parts of the
  # filesystem. While this allows enumerating users, this is already allowed
  # via /etc/passwd and getent.
@{HOMEDIRS}/ r,

# Allow read access to toplevel $HOME for the user
 owner @{HOME}/ r,

There is already other places that allow access to @{HOME}/snap - so that firefox can save it's work stuff. So such reading of root directory contents is unwarranted.

The owner bit in front of @{HOME} does practically nothing because Firefox will always be run by the owner.

I have added a deny to my documents folder. I only want Firefox to be able only to read + write to the Downloads directory. But somehow the Firefox password import file-chooser is able still to navigate the whole drive from root down. How do I change that ? I have removed all mentions of full drive and home directory reads. Is this file-chooser behavior the workings of dbus ?

Thanks.

[DuckHook]

I don't have the technical chops to fine tune FF (or any app) down to such exactitude that I can be sure its usability vs security balance is ideal. I suspect that very few people aside from a few Linux über‑gurus can be sure that any such efforts are completely secure. Modern browsers are just too complex and bloated to cover off in this way.

Instead, I manage to avoid the whole fine tuning conundrum by sandboxing FF within a container. That way, I can just let FF run unmodified (and therefore with full functionality) while restricting and controlling its access to the rest of my system in a way that is entirely independent of FF's settings. Using this method, FF can read root all it wants because it will be only the container's root and not my base system's root. And because the container runs FF and only FF, I don't risk exposing any of my other apps either.

I use LXD as my container, but one can use Docker, Firejail or even a VM with a full‑on Linux OS. That last is a more bloated option, but with the amount of RAM and storage that most people have these days, it's not really that big a deal. Aside from security, there are many further advantages from the ability to do snapshots and restores to the ability to selectively VPN into different geo regions. In your case, you just set specific directories that the container is privy to. I'm even more paranoid, so I allow no shared directories with my /home at all. Instead, if I need to transfer a file, I SFTP into the container to upload/download the file, then break the SFTP mount as soon as I'm done.

I know that I haven't technically answered your specific question, but perhaps this alternative solution constitutes a useful answer to your larger issue.

If interested, there is a link in my sig containing a howto towards using LXD.

Fair warning: Installing LXD in and of itself requires a large commitment and comes with its own steep learning curve. I am aware that this is not a good solution to a simple problem. But I can leverage it for far more than FF. I use it for almost all of my apps. So, by learning it once, I can apply it repetitively, which, in my books, is a good return on my investment and a far better solution than trying to fine tune apparmor for every app (with its known fickleness and ultra‑sensitivity).

[vbgf3]

Hi DuckHook,

You have an interesting work around there. A compartmentalized firefox will contain an intrusion, But the attack will still work, definitely now because there is no apparmor profile. And once the attacker obtains a foothold into that compartmentalized setup, she will be able to bring over All her Tools, and try to escape out of the jail. Your solution just delays the attacker. Plus it gives her all the native bins and libraries in the jail. It is better to stop the attack by strictly confining firefox in the first place. I am a security admin, trust me, this apparmor profile must be fixed.

[DuckHook]

I agree that a multi layered defence is always better. The problem I've always found is in tweaking apparmor to just the right balance between security and usability. It's a finicky little beast that has resisted my best efforts. Essentially, I gave up on it in preference to the containment strategy.

I should have surmised that your technical expertise is more than sufficient to the task. Otherwise, you wouldn't have been asking about apparmor in the first place.

As stated, apparmor profiles are out of my league, so I will let others answer your real question.

I would only point out by way of further clarification that an apparmor profile still exists for my FF — it is just the default one that you find too permissive. Moreover, I don't rely on containerization as my only line of defence. My FF has noscript installed and it defaults to no running scripts on any site. There are very few sites that I allow any sort of scripts to run and even then, only the minimum needed to allow bare functionality. I also have ghostery installed. Moreover, I practice rigorous surfing hygiene. Between the three, a malicious script would find it hard going (but admittedly not impossible) to get established.