> 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.
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. > 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*". 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 On Tue, 6 May 2025 at 16:52, intrigeri <intrig...@debian.org> wrote: > > Control: tag -1 + wontfix > > Hi, > > Jarl Gullberg (2025-05-06): > > That's correct - it ships unconfined, but when set to complain or enforce > > crun is unusable. > > 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. > > > 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. > > 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, > -- > intrigeri
