My guess would be that Apparmor should in principle take precedence since its policies are enforced at the kernel level while Firejail uses userspace sandboxing.
Not sure but interesting question nevertheless.
Interestingly:
It is recommended to only use AppArmor OR Firejail but not both at the same time for the same app. If you set a tight AppArmor profile already then you may want to stick with that.
From the same FAQ
Many times they will cancel each other out. Damn this is not looking good.
I understand that firejail uses SUID to mount a virtual filesystem, different from the OS, to effectively sandbox the process and its child processes. And running mount without root will be difficult. That obviously results in an attack vector.
Having said that firejail’s ability to enforce seccomp is very powerful pull. Along with its ability to spoof the machine ID kept in /etc/machine-id, deny the ability to make RAM/memory blocks that are both writable and executable and many others.
So maybe the trick is to have a more permissive firejail profile while having a restrictive AppArmor profile which blocks many Linux capabilities. Or allow firejail to implement the seccomp and other LSM modules while what can be blocked with AppArmor should be handled exclusively by AppArmor.
What I do not understand is what is written in the FAQ, AppArmor is mandatory when enabled. Does that mean if we add the parameter lsm=landlock,lockdown,yama,integrity,apparmor,bpf to the GRUB command line then AppArmor will be used by default? Or does this mean something else?
There’s also Bubblejail which I haven’t tried.