1. Forum
  2. Usenet
  3. LINUX.DEBIAN.BUGS.DIST

  • Bug#1104603: [pkg-apparmor] Bug#1104603: apparmor: crun profile makes c

    From intrigeri@21:1/5 to All on Tue May 6 15:00:01 2025
    Control: tag -1 + moreinfo

    Hi,

    Jarl Gullberg (2025-05-02):
    The AppArmor profile for crun that ships with AppArmor 4.1 in Debian 13 is currently
    rendering crun entirely unusable when enabled.

    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,
    --
    intrigeri

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From intrigeri@21:1/5 to All on Tue May 6 17:00:01 2025
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)