AppArmor profile installation fails with parsing error in SPO 0.9.0

[MeSabya]

What happened:
While installing Security Profiles Operator (SPO) v0.9.0 with AppArmor enabled, the operator fails to install the spo-apparmor.yaml profile. The following error is observed in the logs:

I0625 06:21:05.198512   97163 nonrootenabler.go:143] "Installing apparmor profile: /opt/spo-profiles/spo-apparmor.yaml" logger="non-root-enabler"
E0625 06:21:05.202811   97163 main.go:246] "running security-profiles-operator" err="installing apparmor profile: installing apparmor profile: running action: load policy: parsing profile: exit status 1" logger="setup"
This suggests a failure in parsing or loading the AppArmor profile despite the file being copied successfully.

What you expected to happen:
The AppArmor profile spo-apparmor.yaml should be successfully parsed and loaded by the operator without any errors.

How to reproduce it (as minimally and precisely as possible):
Deploy SPO v0.9.0 in a Kubernetes cluster.

Ensure AppArmor is enabled on the host (e.g. sudo aa-status).

Let the operator install default AppArmor profiles.

Check the SPO Daemon logs for errors related to profile installation.

Anything else we need to know?:
The spo-apparmor.yaml file is being copied successfully to the expected location.

The issue appears only during the profile load stage.

Might be related to profile format or AppArmor parser incompatibility with certain host configurations.

Environment:
Cloud provider or hardware configuration: VM

OS (e.g: cat /etc/os-release): Debian

Kernel (e.g. uname -a): 6.12.0-1-amd64

Others:

SPO version: v0.9.0

Kubernetes version: v1.30.x

AppArmor status: enabled (aa-status confirms profiles loaded)

[ccojocar]

You can try to run aa_parser to get more information about the error with the spo apparmor profile stored on the host VM:

sudo apparmor_parser -r /etc/apparmor.d/<spo-apparmor-profile-file>

[MeSabya]

sudo apparmor_parser -r /etc/apparmor.d/

It fails at line -1 citing unrecognized token.

[ccojocar]

It sounds like an incompatibility issue in the apparmor.

Which version of Debian is this? Is it vanilla or do you have a custom kernel?

[MeSabya]

Yes its custom kernel , information is captured below:

dpkg -l | grep linux-image
ii linux-image-6.12.0-1-amd64-unsigned 6.12.18-1.stx.116 amd64 Linux 6.12 for 64-bit PCs
ii linux-image-stx-amd64 6.12.18-1.stx.116 amd64 Linux for 64-bit PCs (meta-package)

[sysadmin@controller-1 ~(keystone_admin)]$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

[MeSabya]

For the time being can i use the code below instead of artifact.ReadProfile in the original code.

func (*defaultImpl) InstallApparmor(_ apparmorprofile.ProfileManager, filename string) error {
    cmd := exec.Command("kubectl", "apply", "-f", filename)
    out, err := cmd.CombinedOutput()
    if err != nil {
        return fmt.Errorf("kubectl apply failed: %v\nOutput: %s", err, string(out))
    }
    return nil
}

Please help in case you see any concern.

[rahulroshank]

I looked into the above issue and here is my 2 cents:

Root Cause-
The default AppArmor profile template in spo-apparmor.yaml used this line:
profile {{.Name}} flags=({{.ProfileMode}},attach_disconnected,mediate_deleted)

{{.ProfileMode}} was defined as enforce, causing the rendered profile to be invalid for apparmor_parser v2.13.6 in Debian 11 (Bullseye) to parse. But same default profile was parsed successfully by apparmor_parser 3.0.4 version

patched the Go code that renders this profile by removing {{ Unknown macro: { {.ProfileMode}
rebuilt the SPO image and used this new image.

Note:- Since default profiles are applied in enforced mode it wont have any problem. Problem may arise when user apparmorprofiles with complain mode comes into picture; when applied they will fall in enforce mode.

Result -
After the fix, the default profile (spo-apparmor) loaded successfully at SPO startup.
Verified via:
/etc/apparmor.d/spo-apparmor
aa-status on the node
spod is up and running