Dear Maintainer, The AppArmor profile for crun that ships with AppArmor 4.1 in Debian 13 is currently rendering crun entirely unusable when enabled. crun utilizes a security feature wherein it copies itself into memory and seals the file descriptor to that portion (create_memfd), however, that functionality appears to be interacting badly with AppArmor. As crun does this as its first operation at startup, crun fails before any useful code can execute and bails out. Here are some relevant logs from executions of crun with the profile in complain and disabled mode, respectively: https://gist.github.com/Nihlus/38b6d32aca1bc3e99f7de2a1ab8973c5 I've included both dmesg (cleared before executing crun) and an strace of both a successful and failing execution. The relevant code in crun that's failing is here: https://github.com/containers/crun/blob/1.21/src/crun.c#L438 Let me know if there's any additional information I can provide. Please ignore the mass of changes to other profiles - I was turning things on and off en masse while testing.
Hi, Jarl Gullberg (2025-05-02): What do you mean with "when enabled" here? I'm asking because: - This profile is intentionally shipped in unconfined mode, as explained in the comment on top of the file. - In this default configuration, on current sid, crun fails with "please specify a command", which matches what I understand is your desired successful status, and not the failure (where I would see "Failed to re-execute libcrun via memory file descriptor"). If by "when enabled" you mean "when manually switched from unconfined to complain mode", then I think that's 1 other instance of "complain mode blocks stuff when it should not", which IIRC is tracked upstream somewhere. Other limitations include "'deny' rules will be enforced even in complain mode" (quoting aa-complain(8)). Cheers,
That's correct - it ships unconfined, but when set to complain or enforce crun is unusable. It's fairly common to require all installed apparmor profiles to be set as enforcing when doing security audits / certifications (or have a damn good documented reason why it's not), which is how I stumbled over this. It was working in Debian 12, though saying that I'm actually not sure if a crun profile was shipped at all in bookworm.
Hi, Jarl Gullberg (2025-05-06): Thank you for confirming. IMO this profile behaves as intended and the comment it includes seems sufficient to me to discourage most users from setting it to anything but unconfined, so I'm going to mark this bug wontfix. It's not super actionable anyway, even if one disagrees with my assessment, so whether we keep this open or wontfix or close probably won't matter in practice. Wow, this feels like a very simplistic guideline to me. I'm not particularly motivated to spend any time facilitating its implementation, but still, my last 2 cents on this topic: I would hope a "damn good documented reason why it's not" can be "upstream and the distro maintainers have decided to ship a profile in non-enforcing mode and we trust that they know what they're doing, so perhaps we should not blindly override their decision *by default*". If not, I hope the comment on top of those files will be sufficient to satisfy the needs of anyone who has to comply with the aforementioned rule: # This profile allows everything and only exists to give the # application a name instead of having the label "unconfined" Cheers,
That's totally fair. Since it is an upstream profile the report should probably be pushed there instead - I'll look into that unless you have a faster way to get the right eyes on it. Without going too far into the weeds on this, the guideline exists to facilitate a few specific things - namely, if you have decided on a policy for something, it should be enforced or at the very least audited for compliance. Even if the policy is "allow everything", that "allow everything" should be explicitly enforced through the mechanisms available. The distinction between unconfined (don't enforce the policy, whatever it might be) and enforce (enforce the policy, and if it happens to be allow everything, that's a conscious decision that might change) is quite important when arguing for security compliance. Documenting it as having made an active choice to leave it unconfined is something you'd definitely see in compliance documentation, so it's definitely not the end of the world. The profile simply not working as intended when in complain or enforce mode is separate from that. Thanks, Jarl