Amazon-ssm-agent AppArmor profile not allowing "enforce" mode


We’ve got a CIS security requirement that all of our AppArmor profiles are in “enforce” mode and none are in “complain” mode. When we create an instance from the official Ubuntu AMI, it’s already got the “amazon-ssm-agent” (link below) installed as a “Snap”, along with its AppArmor profiles:

# apparmor_status
apparmor module is loaded.
24 profiles are loaded.
22 profiles are in enforce mode.
2 profiles are in complain mode.
3 processes have profiles defined.
2 processes are in enforce mode.
   /sbin/dhclient (1097)
   /usr/sbin/rsyslogd (1262)
1 processes are in complain mode. (11647)

However, when I try to put this profile into “enforce” mode using the “aa-enforce” command, I keep getting errors, either complaining that the “failed to find binary, not on PATH” or “no profile found that matches that binary”:

# aa-enforce /snap/amazon-ssm-agent/current/amazon-ssm-agent
Profile for /snap/amazon-ssm-agent/295/amazon-ssm-agent not found, skipping

# aa-enforce
Can't find in the system path list. If the name of the application
is correct, please run 'which' as a user with correct PATH
environment set up in order to find the fully-qualified path and
use the full path as parameter.

# aa-enforce amazon-ssm-agent
Profile for /usr/bin/amazon-ssm-agent not found, skipping

# aa-enforce /snap/amazon-ssm-agent/295/amazon-ssm-agent
Profile for /snap/amazon-ssm-agent/295/amazon-ssm-agent not found, skipping


What is going on here? Why can’t I put this profile/process into “enforce” mode? Is this an issue with the snap, with AppArmor or something else? Has anyone else had issues similar to the above?

I’ve opened an issue in the “amazon-ssm-agent” GitHub (see below) as I’m not sure where exactly the issue lies.

NOTE: Also, it would be nice to have a link to the snap source code/home page/issue tracker from the page for each snap.

Note that the ssm snap uses ‘confinement: classic’. As such, while an apparmor profile is generated for the snap, it is only there so that the snap’s processes have a security label. The actual policy itself is (intentionally) wide open and effectively unconfined. We add ‘complain’ to the profile flags to help guard against any bugs and fd revalidation. Put another way, even if you removed the complain flag, it wouldn’t satisfy any practical requirements with enforcing a restrictive policy.

As for ‘aa-enforce’, snapd manages its own policy in /var/lib/snapd/apparmor/profiles (with its cache in /var/cache/apparmor) and system policy tools like ‘aa-enforce’ aren’t meant to operate on them (and thus do not support this location). Even if aa-enforce could update the file, snapd ensures that the profiles in /var/lib/snapd/apparmor/profiles contain what it expects, and snapd would revert the change at some point.

All said, it would be best to adjust your requirements to consider that ‘confinement: classic’ snaps are not actually confined (they should be thought of as equivalent to debs in a lot of ways).

Wow! Thank you for that, that’s a really excellent answer. I have put in a workaround to basically “ignore” this one profile/process in complain mode, so I guess that’s going to stay for the time being.

system policy tools like ‘aa-enforce’ aren’t meant to operate on them (and thus do not support this location)

Ok, that’s understandable, though it would be nice if this is the case that it doesn’t show up under the output of “apparmor_status”. Or that it shows up, but mentions that it’s not a “system policy” and therefore not managed by the usual tools.

Should I create an issue for the “ssm-agent” Snap to upgrade away from “confinement: classic”? Would this result in a more limited AppArmor profile?

Also, would moving away from “confinement: classic” allow the user/operator to be able to configure whether the Snap was in “enforce” or “complain” mode? Or would it still be under the control of the Snap author?