Fedora 26 LXD container: cannot load apparmor profile
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
snapd |
Triaged
|
High
|
Unassigned |
Bug Description
In a Fedora 26 LXD container (images:
$ sudo snap install htop
error: cannot perform the following tasks:
- Setup snap "core" (2898) security profiles (cannot setup apparmor for snap "core": cannot load apparmor profile "snap.core.
apparmor_parser output:
)
- Setup snap "core" (2898) security profiles (cannot load apparmor profile "snap.core.
apparmor_parser output:
)
$ apparmor_parser
bash: apparmor_parser: command not found
There's some AppArmor files bleeding into the container:
/sys/module/
/sys/kernel/
However, even mocking them out via 'sudo mount -t tmpfs none /sys/module/; sudo mount -t tmpfs none /sys/kernel/
Work-around: sudo ln -s /usr/bin/true /usr/bin/
Changed in snappy: | |
status: | New → Triaged |
importance: | Undecided → High |
affects: | snappy → snapd |
can you correct me if my interpretation of your setup is wrong?
the host is ubuntu with apparmor enabled.
the container is fedora 26
the snap is being installed in the fedora container
and can you provide the output of apparmor/ parameters/ enabled
cat /sys/module/
So first up module/ apparmor will showup if apparmor is builtin to the kernel regardless of whether apparmor is enabled. This will always appear on Ubuntu kernels and several other distro kernels
/sys/
and kernel/ security/ apparmor will only show up if it is the registered LSM on the system.
/sys/
if I am correct about your setup, then I can explain what is happening.
Containers and hosts share a kernel, and the LSM is not namespaced or virtualized, so the LSM enabled on the host is the LSM for the container as well.
Your fedora container does not have the apparmor package installed so it is not trying to load apparmor policy and it is missing the apparmor_parser.
Snappy detects the kernel supports apparmor and tries to load the policy for the snap and fails.
Unfortunately at this time while apparmor supports policy namespaces and stacking with it self. It does not support virtualizing whether it is enabled for a given policy namespace. This means that because the kernel has apparmor enabled, the container even when setup with see apparmor enabled.
The virtualization of the apparmor module parameters is scheduled to land in the 4.15 kernel and will be backported into the current ubuntu kernels as some point. Until then a bind mount in the container over /sys/module/ apparmor/ parameters/ enabled to a file that contains just 'N' should make apparmor appear to be disabled (assuming snappy is using the standard checks for apparmor).