AppArmor and Firefox: Error message

[curiosityseeker]

I'm aware of the warnings about using Firejail and AppArmor at the same time. In particular, I cannot confirm the following statement so far - at least, not for Firefox on Arch Linux:

You need to add more privileges in AppArmor than is needed without firejail, and you need to use less firejail features otherwise it would be broken with AppArmor.

When I created my Firefox AppArmor profile, aa-logprof suggested to add the following rules, indeed:

/usr/bin/firejail mrix,
/run/firejail/lib/lib*so* mr,
/run/firejail/mnt/fslogger r,

At first, I added them - but now I removed those rules again without any noticeable side-effects. Firefox is confined by AppArmor and sandboxed by Firejail.

However, if I start Firefox in the console I'm seeing the following error message:

ERROR: ld.so: object '/run/firejail/lib/libpostexecseccomp.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.

What does this error message mean? Is this something I should be concerned about?

[smitsohu]

@adrelanos some time ago pointed us to https://gitlab.com/apparmor/apparmor/issues/50, and I still wonder if that solution could make everyone happy in the end.

The only remaining issue would be nonewprivs/seccomp breaking profile transitions in AppArmor profiles... if there are any.

At first, I added them - but now I removed those rules again without any noticeable side-effects.

That's probably because you have a symbolic link /usr/local/bin/firefox -> /usr/bin/firejail, and one time you started the sandbox as firejail firefox and another time as firefox.

What does this error message mean? Is this something I should be concerned about?

I think it tries to tell you that seccomp is (partially) broken. You can confirm this by running --seccomp.print against the sandbox. So yes, access to /run/firejail/lib/libpostexecseccomp.so is probably something you want to allow.

[smitsohu]

You can confirm this by running --seccomp.print against the sandbox.

Sorry, just realize that actually you cannot.

Anyway, it is rather important to give access to libpostexecseccomp.so.

[curiosityseeker]

The only remaining issue would be nonewprivs/seccomp breaking profile transitions in AppArmor profiles... if there are any.

Thanks, I have to read that thoroughly.

You can confirm this by running --seccomp.print against the sandbox.

Sorry, just realize that actually you cannot.

Anyway, it is rather important to give access to libpostexecseccomp.so.

Okay, I added back /run/firejail/lib/libpostexecseccomp.so mr,and that error is gone now. Nevertheless, it would be interesting to know if there is another method to find out if seccomp is really broken without that rule.

[smitsohu]

Nevertheless, it would be interesting to know if there is another method to find out if seccomp is really broken without that rule

First compile https://github.com/netblue30/firejail/blob/master/src/tools/extract_seccomp.c
gcc -o extract_seccomp extract_seccomp.c

and run it like extract_seccomp <PID>. It gets the seccomp filters right from the kernel and writes them in a directory in /tmp. Then you can run /usr/lib/firejail/fsec-print on the output files and compare the output to --seccomp.print.

[smitsohu]

Firefox render processes always have one seccomp filter extra, which is the built-in Firefox sandbox.

Just in case you wonder.

[curiosityseeker]

Nevertheless, it would be interesting to know if there is another method to find out if seccomp is really broken without that rule

First compile https://github.com/netblue30/firejail/blob/master/src/tools/extract_seccomp.c
gcc -o extract_seccomp extract_seccomp.c

and run it like extract_seccomp <PID>. It gets the seccomp filters right from the kernel and writes them in a directory in /tmp. Then you can run /usr/lib/firejail/fsec-print on the output files and compare the output to --seccomp.print.

Thanks for this explanation and providing those tools! When executing ./extract_seccomp 8758 (the latter being the PID of my Firefox) I got the error:

** Attaching to process with pid 8758 **
Error: Cannot attach: Operation not permitted

Starting it with sudo worked, though. Now I have to analyze the output ...

[smitsohu]

Now I have to analyze the output

Actually it is not necessary to understand the output, by just counting the filters it should be evident there is one less.

[smitsohu]

This and most other issues should've been fixed by https://gitlab.com/apparmor/apparmor/-/merge_requests/345

@curiosityseeker can you confirm the line
/{usr/,}lib{,32,64}/**.so* mr,
is absent from your /etc/apparmor.d/abstractions/base ?

I'm not sure if it is a good idea to expose the Firejail binary itself, which is setuid-root after all, in all AppArmor profiles.

[curiosityseeker]

Now I have to analyze the output

Actually it is not necessary to understand the output, by just counting the filters it should be evident there is one less.

Sorry, I had actually forgotten about this. I'll do that once I find the time.

[curiosityseeker]

This and most other issues should've been fixed by https://gitlab.com/apparmor/apparmor/-/merge_requests/345

@curiosityseeker can you confirm the line
/{usr/,}lib{,32,64}/**.so* mr,
is absent from your /etc/apparmor.d/abstractions/base ?

I'm not sure if it is a good idea to expose the Firejail binary itself, which is setuid-root after all, in all AppArmor profiles.

No, that line is present in abstractions/base:

 # we might as well allow everything to use common libraries
  /{usr/,}lib{,32,64}/**                r,
  /{usr/,}lib{,32,64}/**.so*       mr,
  /{usr/,}lib/@{multiarch}/**            r,
  /{usr/,}lib/@{multiarch}/**.so*   mr,
  /{usr/,}lib/tls/i686/{cmov,nosegneg}/*.so*    mr,
  /{usr/,}lib/i386-linux-gnu/tls/i686/{cmov,nosegneg}/*.so*    mr,

[smitsohu]

@curiosityseeker can you confirm the line
/{usr/,}lib{,32,64}/**.so* mr,
is absent from your /etc/apparmor.d/abstractions/base ?

No, that line is present in abstractions/base:

I'm sorry, I confused the paths. The base abstraction doesn't grant access to /run/firejail/lib/libpostexecseccomp.so, which caused the original error.

Proposal for a /etc/apparmor.d/abstractions/base.d/firejail (or whatever the name; untested)

# Basic support for using stock AppArmor profiles with Firejail.
# Note that Firejail's nonewprivs and seccomp options are not
# compatible with some AppArmor profile transitions.

# library preloading
/run/firejail/lib/*.so mr,

# discovery of process names
owner @{PROC}/@{pid}/comm r,

# supporting seccomp
owner /run/firejail/mnt/seccomp/seccomp.postexec r,

# supporting trace
owner /run/firejail/mnt/trace w,

# supporting tracelog
/run/firejail/mnt/fslogger r,

[curiosityseeker]

I think that's a good idea as it would make it easier to add those rules to one's own AppArmor profiles.

Note that I have in my Thunderbird profile the following rule:
owner /proc/*/comm r,

So some of above rules might be hardened be modifying them to owner conditional rules.

Another aspect - discussed here - is that obviously the attach_disconnected flag is needed for specific requests. And as a matter of fact, that flag and mediate_deleted are used in the firejail-default profile. Unfortunately, I found it difficult to find a reasonable documentation for those flags (particularly for the latter) to evaluate what these flags are really doing and if they implicate specific risks. E.g., the AA Core Policy Reference says about attach_disconnectedthat it "is generally not considered a good idea as it allows disconnected paths to alias to other files that exist in the file name." while the OpenSuSE documentation doesn't mention this warning. (And both sources don't mention mediate_deleted at all).

(EDIT: I found this info about mediate_deleted in the AppArmor FAQ)

I wonder if those flags are needed for all AA profiles in combination with Firejail. But they can't be added by an abstraction anyhow.

Btw - a probably crazy idea (not really related to this discussion) comes to my mind: Would it be feasible to create an AA profile for /usr/bin/firejail that allows everything needed but restricts/blocks all operations related to the risk of firejail being a SUID executable?

[smitsohu]

There is some mediate_deleted related documentation here: https://gitlab.com/apparmor/apparmor/-/wikis/FAQ#what-causes-failed-name-lookup-and-how-do-i-fix-it
It seems to suggest that mediate_deleted actually adds to the restrictions, but I'm not entirely clear about all the implications.

Would it be feasible to create an AA profile for /usr/bin/firejail that allows everything needed but restricts/blocks all operations related to the risk of firejail being a SUID executable?

Writing an AppArmor profile for Firejail itself is certainly possible. But as Firejail requires very broad permissions (only think of blacklisting and whitelisting), I doubt you would end up with a meaningful restriction.

What might make sense though is to have dedicated AppArmor profiles for Firejail's various helper programs (for example fcopy).

[smitsohu]

Note that I have in my Thunderbird profile the following rule:
owner /proc/*/comm r,

So some of above rules might be hardened be modifying them to owner conditional rules.

Thanks! I updated the comment accordingly.

[rusty-snake]

Anything left here?

[kris7t]

Btw, would it be useful at all to let users set their own AppArmor profiles (instead of firejail-default), or maybe even to generate AppArmor profiles on the fly (if that's feasible) from firejail profiles?

[curiosityseeker]

Btw, would it be useful at all to let users set their own AppArmor profiles (instead of firejail-default),

That's already possible by adding ignore apparmor to the Firejail profile. In that case firejail-default is no longer used but rather the AppArmor profile for the respective application (if it exists).

or maybe even to generate AppArmor profiles on the fly (if that's feasible) from firejail profiles?

I doubt that's feasible. If such an AA profile should not break an application the rules therein must be rather unspecific to take account of, e.g., various DE's. I'm not sure if such an AA profile offers real added value. And if it's specific enough users have to learn AA syntax and logic as well to unbreak applications. I'm afraid we would have considerably more support issues her.

[curiosityseeker]

Anything left here?

I don't think so. However, I must admit that I'm no longer terribly interested in this issue. The reason is that - after countless tries - I no longer use Firejail for Thunderbird, Firefox and Cherrytree but run those applications in AA profiles. Simply because I wasn't able to execute helper applications (like Okular, Gwenview and LibreOffice) running in their own sandbox or, at least, in their own AA profile.

This problem was already discussed at length in this issue. E.g., when I click a PDF attachment in Thunderbird I've managed to open it in Okular - unfortunately it's not running in its own sandbox but within the Thunderbird sandbox (which means that Okular has access to everything in ~/.thunderbird). If I combine Firejail with AppArmor I'm only able to execute those helper applications in ix mode (with the same result as above). Ths is even true if the Firejail profile only contains seccomp and nothing else.

That's why I wrote my own strict AA profiles for those helper applications. Now I can execute them from, e.g., (unfirejailed) Thunderbird in Px mode which means that the helper application runs in its own profile with zero access to ~./thunderbird.

Perhaps I wasn't able to see the forest for the trees any more after countless unsuccessful tries but finally I gave up to find a working solution with Firejail. I think this problem is one of the most annoying weaknesses in Firejail. I guess it's caused by the namespaces used in Firejail, and I have no idea if there is a potential solution at all.

[smitsohu]

Namespaces and seccomp have no notion of transitions between security domains. If we want these transitions (e.g. from an email client sandbox to a pdf viewer sandbox), we will have to work around the limitation by ourselves. It is not necessarily impossible, for example we could mount a tiny helper on top of the pdf viewer binary, and expose a simple service on the D-Bus session bus which does nothing but starting sandboxed pdf viewer instances. Then every attempt to start the viewer from inside the sandbox would be redirected to our service on the session bus.

No idea how easy or difficult it would be to get it right, though. Transitions between security domains can be tricky, and AppArmor, just as a side note, is known to have its own set of unresolved problems, arising from incomplete sanitizing of the environment (an attacker in sandbox 1 can play creatively with environment variables like PATH, GTK_PATH, GTK_MODULES, PYTHONPATH and so on to achieve arbitrary code execution in a less strict sandbox 2 after, say, a Px transition).

[smitsohu]

Btw, would it be useful at all to let users set their own AppArmor profiles
(instead of firejail-default),

That's already possible by adding ignore apparmor to the Firejail profile. In that case firejail-default is no longer used but rather the AppArmor profile for the respective application (if it exists).

That's right, but being able to freely specify AppArmor profiles is still more flexible. There could be:

1. the application's upstream AppArmor profile
2. Firejail's upstream AppArmor profile
3. heavily modified versions of 1 or 2

Currently there is no way from within Firejail to load a profile of category 3.

or maybe even to generate AppArmor profiles on the fly (if that's feasible) from firejail profiles?

I've been wondering that, too. One related question would be why AppArmor doesn't allow ordinary users to load profiles in the kernel anyway.

[curiosityseeker]

Namespaces and seccomp have no notion of transitions between security domains. If we want these transitions (e.g. from an email client sandbox to a pdf viewer sandbox), we will have to work around the limitation by ourselves. It is not necessarily impossible, for example we could mount a tiny helper on top of the pdf viewer binary, and expose a simple service on the D-Bus session bus which does nothing but starting sandboxed pdf viewer instances. Then every attempt to start the viewer from inside the sandbox would be redirected to our service on the session bus.

No idea how easy or difficult it would be to get it right, though. Transitions between security domains can be tricky,

That's an interesting idea. I wonder if it were possible to apply that tiny helper not only to, e.g., a specific PDF viewer but to all kinds of applications ... I guess that helper would also need a ruleset for the applications it would be applied to.

and AppArmor, just as a side note, is known to have its own set of unresolved
problems, arising from incomplete sanitizing of the environment (an attacker in
sandbox 1 can play creatively with environment variables like PATH, GTK_PATH,
GTK_MODULES, PYTHONPATH and so on to achieve arbitrary code execution in a less > strict sandbox 2 after, say, a Px transition).

Could you elaborate, please? I'm not sure what you mean exactly. Any sources or examples?

[glitsj16]

That's an interesting idea. I wonder if it were possible to apply that tiny helper not only to, e.g., a specific PDF viewer but to all kinds of applications ... I guess that helper would also need a ruleset for the applications it would be applied to.

This reminds me of the xdg-open wrapper I mentioned a while back. If we could bring that into firejail we might not even need D-Bus and could use its native MIME-type support. Sadly the referenced scripts in that old thread are no longer reachable (ptpb.pw being dead). I do still use a similar 'drop file' technique ever since (limited to notifications and hyperlinks) for crude-but-working inter-sandbox communication. If anyone's interested, I can put them on gist.github.com.

[smitsohu]

Could you elaborate, please? I'm not sure what you mean exactly. Any sources or examples?

Originally reported in http:https://blog.azimuthsecurity.com/2012/09/poking-holes-in-apparmor-profiles.html and tracked in https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1045985 . Nothing to be concerned about when transitioning to a more restrictive profile, there is an issue only when transitioning to something less restrictive. It was meant just as an illustration of the pitfalls that are luring here (admittedly somewhat unlucky, as this particular issue wouldn't affect Firejail).

This reminds me of the xdg-open wrapper I mentioned a while back. If we could bring that into firejail we might not even need D-Bus

Nice idea, access to the service could be controlled by write access to a directory.

[curiosityseeker]

Originally reported in http:https://blog.azimuthsecurity.com/2012/09/poking-holes-in-apparmor-profiles.html and tracked in https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1045985 . Nothing to be concerned about when transitioning to a more restrictive profile, there is an issue only when transitioning to something less restrictive. It was meant just as an illustration of the pitfalls that are luring here (admittedly somewhat unlucky, as this particular issue doesn't affect Firejail).

Thanks, interesting! However, when writing my own profiles I never ever use Ux (and certainly not ux), Pix or the Sanitized Helper. ;)

[curiosityseeker]

That's right, but being able to freely specify AppArmor profiles is still more flexible. There could be:

1. the application's upstream AppArmor profile

2. Firejail's upstream AppArmor profile

3. heavily modified versions of 1 or 2

While I agree in general, we have to answer some questions:

1. The wiki says:

It is recommended to only use AppArmor OR firejail but not both at the same time for the same app. ... You need to add more privileges in AppArmor than is needed without firejail, and you need to use less firejail features otherwise it would be broken with AppArmor. Many times they will cancel each out rather than complement.

Does that claim still stand?

2. Would we be really able to inform people that they have to add, e.g., /run/firejail/lib/libpostexecseccomp.so mr, to their AA profiles (or, better yet, to the ones in /etc/apparmor.d/local if they use predefined profiles to prevent them to get overwritten with every AppArmor update)? If not, a lot of issues are predictable.

3. Would we be able to write modified AA profiles that do not collide with Firejail and to make sure that they would replace the upstream AA profiles?

[topimiettinen]

With SELinux it's possible to move between different domains with different rules, even more permissive, so I wonder why this would not possible with AA?

There are no SELinux rules for Firejail yet, but I'm working on those.

[curiosityseeker]

@glitsj16

This reminds me of the xdg-open wrapper I mentioned a while back. If we could bring that into firejail we might not even need D-Bus and could use its native MIME-type support. Sadly the referenced scripts in that old thread are no longer reachable (ptpb.pw being dead). I do still use a similar 'drop file' technique ever since (limited to notifications and hyperlinks) for crude-but-working inter-sandbox communication. If anyone's interested, I can put them on gist.github.com.

Yes, please! I'm definitely interested!

[curiosityseeker]

Namespaces and seccomp have no notion of transitions between security domains.

Just adding that even using child profiles or named profile transitions do not work. I tried something like:

/{usr/,}bin/okular Cx -> okular,

....

profile okular {
    #include <abstractions/base>

    /{usr/,}bin/okular mrix,
    ...

  }

but to no avail.

[glitsj16]

@curiosity-seeker Apologies for the late reply. I couldn't recover the old pastebin files, but I rewrote them from scratch.

I put the files in two repositories: firejail-handler-http and firejail-handler-extra.

Arch Linux users can try firejail-handler-http and/or firejail-handler-extra.

Feel free to test and comment as you see fit. There is probably room for improvement, so any feedback is very much appreciated.

[curiosityseeker]

@glitsj16 : Thanks a lot for this! I will try to test this in the coming days and will certainly report how it will go!

[curiosityseeker]

@smitsohu : Many thanks for adding this abstraction. As already mentioned in discussions, it works flawlessly with Firefox.

EDIT: The previously mentioned error message for Brave and Thunderbird is pointless. However, in Thunderbird I can't open links in Firefox anymore.

Now if you also find a solution to allow for profile transitions that would be fantastic :-)