modif: allow userns in firejail-default apparmor profile

[cobratbq]

Add userns to the AppArmor profile for firejail, such that with AppArmor enforcing restrictions, firejail is granted sufficient permissions to exert full control over the capabilities and permissions it is managing.

Fixes: #7078

• question: Is the child-process of firejail already properly handled w.r.t. the AppArmor profile? Already before this patch, the spawned firejail child-process would likely be subjected to some influence from apparmor, or not?

The open question should not matter more/less specifically for this patch.

[kmk3]

@cobratbq on Feb 25:

IIUC, adding userns to the AppArmor-profile for firejail is effectively the
same as previous AppArmor without this addition, because it only recent got
to being managed. It effectively allows user-namespaces thus deferring to
firejail to determine whether to continue to allow it.

Nice, since this makes the profile work the same as in AppArmor 3, sounds
good to me.

Assuming that this abi/4.0 indicates a "language" version, thus available
keywords, then AppArmor 3 would likely reject the profile, but would do so
already. (I'm guessing as to its meaning, so I'm not 100% sure.)

Judging by #6675, AppArmor 4 seems to be relatively recent, so I'd expect many
systems to still be using AppArmor 3.x.

If the current profiles work in AppArmor 3.x but fail with this change, then it
might be better to avoid it for now.

Can you test with AppArmor 3.x to confirm what happens?

[kmk3]

Is the child-process of firejail already properly handled w.r.t. the AppArmor
profile? Already before this patch, the spawned firejail child-process
would likely be subjected to some influence from apparmor, or not?

AIUI firejail itself uses a very permissive apparmor profile
("firejail-base"?), then after setting up the sandbox, it applies a more
restrictive one ("firejail-default" I believe) right before starting the
program.

[cobratbq]

Judging by #6675, AppArmor 4 seems to be relatively recent, so I'd expect many systems to still be using AppArmor 3.x.

If the current profiles work in AppArmor 3.x but fail with this change, then it might be better to avoid it for now.

Can you test with AppArmor 3.x to confirm what happens?

I'll see if I can check a couple of things.

We may be able to define profiles with a include <abi/3.0> or include <abi/4.0> as distinguisher. It depends on whether AppArmor understands to silently skip the incompatible profile. It seems firejail-default does not currently include any definition of an ABI, thus making it compatible with older versions.

Converted to draft to reflect the open issue.

[kmk3]

Judging by #6675, AppArmor 4 seems to be relatively recent, so I'd expect
many systems to still be using AppArmor 3.x. If the current profiles work
in AppArmor 3.x but fail with this change, then it might be better to avoid
it for now. Can you test with AppArmor 3.x to confirm what happens?

I'll see if I can check a couple of things.

We may be able to define profiles with a include <abi/3.0> or include <abi/4.0> as distinguisher. It depends on whether AppArmor understands to
silently skip the incompatible profile. It seems firejail-default does not
currently include any definition of an ABI, thus making it compatible with
older versions.

Good catch.

Maybe AppArmor 4 assumes abi/4.0 by default (such as by implicitly including
<abi/4.0> if no other <abi/x> is included).

So if we just add include <abi/3.0> and target 3.x, maybe it would allow user
namespaces by default, just like with AppArmor 3.x.

Edit: That is, just for the sake of fixing the user namespace support (and the
profile in general, as other things could be broken as well).

Then we could add a specific profile for 4.x, etc.

[cobratbq]

Some AppArmor notes:

• AppArmor 3.0 release notes
• abi feature introduced in AppArmor 3.0.
• AppArmor 4.0 release notes
• Distrowatch: Debian
  • 13: 4.1
  • 12: 3
  • 11: 2.13.6
  • 10: 2.13.2
• Distrowatch: Ubuntu
  • newer: 3.0 or higher
  • 20.04 LTS: 2.13.3

[netblue30]

Thanks @cobratbq. It seems to be working fine on Debian stable, but let's wait until next week. We have a new release coming over the weekend, we'll merge it in after that.

[cobratbq]

Thanks @cobratbq. It seems to be working fine on Debian stable, but let's wait until next week. We have a new release coming over the weekend, we'll merge it in after that.

So, I'm not sure what the desired solution is for the profiles? I don't think you can write one profile version, so you would have to conditionally package one conditional on AppArmor version. That's been bugging me a bit.

On another note:

Well, if that's in place. Any chance you can check out running Firefox without apparmor-replace? I got asked, so I was curious and checked just now. I think it just works:

• Firefox apparmor-profile enables userns in unconfined mode;
• Firejail in enforcing mode for me;
• running firejail with --apparmor and --ignore=apparmor-replace.

Apparmor ends up in a mixed-mode setup of Firejail enforcing and Firefox unconfined. (I think)