Description updated with the SRU template information.
** Description changed:
- We've recently noticed a lot of the LXD CI jobs failing because of
- apparmor related snapd issues.
+ [ Impact ]
- The way this usually manifests is:
- - lxc launch images:ubuntu/20.04 c1
- - lxc exec c1 -- apt install snapd
- - lxc exec c1 -- snap install distrobuilder --edge --classic
- - lxc exec c1 -- distrobuilder
+ The apparmor_parser before the 3.0 release would build its capability list
from the installed kernel headers. The apparmor_parser was built against a
kernel without support for cap 'bpf'
+ This was fixed in 3.0 by having a static caps list (with full mapping info)
and the dynamic auto-generated list (against the kernel headers) that is used
to check that the static list has not become stale. In addition the parser can
pull kernel supported caps straight from the apparmor kernel module (it will
however be missing the mapping info).
+ Backporting the patches from 3.0 fixes the issue.
- This all works as expected, `systemctl --failed` is clean and
`apparmor_status` gets me:
- ```
- 0 loaded units listed.
- root@v1:~# lxc exec c1 -- apparmor_status
- apparmor module is loaded.
- 11 profiles are loaded.
- 10 profiles are in enforce mode.
- /usr/lib/NetworkManager/nm-dhcp-client.action
- /usr/lib/NetworkManager/nm-dhcp-helper
- /usr/lib/connman/scripts/dhclient-script
- /usr/lib/snapd/snap-confine
- /usr/lib/snapd/snap-confine//mount-namespace-capture-helper
- /{,usr/}sbin/dhclient
- lsb_release
- nvidia_modprobe
- nvidia_modprobe//kmod
- snap-update-ns.distrobuilder
- 1 profiles are in complain mode.
- snap.distrobuilder.distrobuilder
- 0 processes have profiles defined.
- 0 processes are in enforce mode.
- 0 processes are in complain mode.
- 0 processes are unconfined but have a profile defined.
- ```
+ [ Test Plan ]
- Now to break things:
- - lxc restart c1
- - lxc exec c1 -- distrobuilder
+ Before the fix, the following profile fails loading:
- ```
- root@v1:~# lxc exec c1 -- distrobuilder
- cannot change profile for the next exec call: No such file or directory
- ```
+ # echo "profile foo { capability bpf, }" | apparmor_parser -Q
+ AppArmor parser error, in stdin line 1: Invalid capability bpf.
+ # echo $?
+ 1
- Looking around, we see:
- ```
- root@c1:~# find /var/lib/snapd/apparmor/
- /var/lib/snapd/apparmor/
- /var/lib/snapd/apparmor/snap-confine
- /var/lib/snapd/apparmor/snap-confine/cap-bpf
- /var/lib/snapd/apparmor/profiles
- /var/lib/snapd/apparmor/profiles/snap.distrobuilder.distrobuilder
- /var/lib/snapd/apparmor/profiles/snap-update-ns.distrobuilder
- /var/lib/snapd/apparmor/profiles/snap-confine.snapd.14978
- root@c1:~# cat /var/lib/snapd/apparmor/snap-confine/cap-bpf
+ After the fix, it works as expected:
- capability bpf,
- root@c1:~# systemctl --failed
- UNIT LOAD ACTIVE SUB DESCRIPTION
- ● snapd.apparmor.service loaded failed failed Load AppArmor profiles managed
internally by snapd
+ # echo "profile foo { capability bpf, }" | apparmor_parser -Q
+ # echo $?
+ 0
- LOAD = Reflects whether the unit definition was properly loaded.
- ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
- SUB = The low-level unit activation state, values depend on unit type.
+ [ Where problems could occur ]
- 1 loaded units listed.
- ```
+ With these changes, the parser can change its behavior based on a few things.
+ 1. the kernel its built against. This would not change behavior when run in a
container vs at system level.
- The error listed is:
- ```
- Mar 11 19:54:58 c1 systemd[1]: Starting Load AppArmor profiles managed
internally by snapd...
- Mar 11 19:54:58 c1 snapd-apparmor[163]: /usr/lib/snapd/snapd-apparmor: 47:
ns_stacked: not found
- Mar 11 19:54:58 c1 snapd-apparmor[163]: /usr/lib/snapd/snapd-apparmor: 48:
ns_name: not found
- Mar 11 19:54:58 c1 snapd-apparmor[172]: AppArmor parser error for
/var/lib/snapd/apparmor/profiles/snap-confine.snapd.14978 in
/var/lib/snapd/apparmor/snap-confine/cap-bpf at line 2: Invalid capability bpf.
- Mar 11 19:54:58 c1 systemd[1]: snapd.apparmor.service: Main process exited,
code=exited, st
- ```
+ 2. If a feature-file is specified, via --features-file, --policy-
+ features, or --kernel-features. This allows overriding the normal policy
+ and kernel examination that the parser does when compiling policy.
- One can workaround it with:
- ```
- > /var/lib/snapd/apparmor/snap-confine/cap-bpf
- systemctl restart snapd.apparmor.service
- ```
+ 3. If /sys/kernel/security/apparmor/features is not available. The
+ parser will fallback to an old set of features available in a kernel
+ before the kernel module started exporting what the kernel module
+ supports on the running kernel.
+ [ Other Info ]
- Now for the bits I didn't quite figure out:
- - Why does snapd think that the parser supports `bpf` when it in fact
doesn't?
- - Why does this only seem to hit with `distrobuilder`, testing with
`hello-world` doesn't hit this issue though we've seen similar behavior from
the `go` snap, is it a bug that only triggers on classic snaps?
+ The patches for focal (apparmor-2.13) can be found at:
+ https://launchpad.net/~georgiag/+archive/ubuntu/mqueue-sru/
** Description changed:
[ Impact ]
The apparmor_parser before the 3.0 release would build its capability list
from the installed kernel headers. The apparmor_parser was built against a
kernel without support for cap 'bpf'
This was fixed in 3.0 by having a static caps list (with full mapping info)
and the dynamic auto-generated list (against the kernel headers) that is used
to check that the static list has not become stale. In addition the parser can
pull kernel supported caps straight from the apparmor kernel module (it will
however be missing the mapping info).
Backporting the patches from 3.0 fixes the issue.
[ Test Plan ]
Before the fix, the following profile fails loading:
# echo "profile foo { capability bpf, }" | apparmor_parser -Q
AppArmor parser error, in stdin line 1: Invalid capability bpf.
# echo $?
1
After the fix, it works as expected:
# echo "profile foo { capability bpf, }" | apparmor_parser -Q
# echo $?
0
[ Where problems could occur ]
With these changes, the parser can change its behavior based on a few things.
1. the kernel its built against. This would not change behavior when run in a
container vs at system level.
2. If a feature-file is specified, via --features-file, --policy-
features, or --kernel-features. This allows overriding the normal policy
and kernel examination that the parser does when compiling policy.
3. If /sys/kernel/security/apparmor/features is not available. The
parser will fallback to an old set of features available in a kernel
before the kernel module started exporting what the kernel module
supports on the running kernel.
[ Other Info ]
The patches for focal (apparmor-2.13) can be found at:
https://launchpad.net/~georgiag/+archive/ubuntu/mqueue-sru/
+ As mentioned before, these patches are already running on apparmor-3.0.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1964636
Title:
Incorrect handling of apparmor `bpf` capability
Status in apparmor package in Ubuntu:
In Progress
Status in snapd package in Ubuntu:
Incomplete
Bug description:
[ Impact ]
The apparmor_parser before the 3.0 release would build its capability list
from the installed kernel headers. The apparmor_parser was built against a
kernel without support for cap 'bpf'
This was fixed in 3.0 by having a static caps list (with full mapping info)
and the dynamic auto-generated list (against the kernel headers) that is used
to check that the static list has not become stale. In addition the parser can
pull kernel supported caps straight from the apparmor kernel module (it will
however be missing the mapping info).
Backporting the patches from 3.0 fixes the issue.
[ Test Plan ]
Before the fix, the following profile fails loading:
# echo "profile foo { capability bpf, }" | apparmor_parser -Q
AppArmor parser error, in stdin line 1: Invalid capability bpf.
# echo $?
1
After the fix, it works as expected:
# echo "profile foo { capability bpf, }" | apparmor_parser -Q
# echo $?
0
[ Where problems could occur ]
With these changes, the parser can change its behavior based on a few things.
1. the kernel its built against. This would not change behavior when run in a
container vs at system level.
2. If a feature-file is specified, via --features-file, --policy-
features, or --kernel-features. This allows overriding the normal
policy and kernel examination that the parser does when compiling
policy.
3. If /sys/kernel/security/apparmor/features is not available. The
parser will fallback to an old set of features available in a kernel
before the kernel module started exporting what the kernel module
supports on the running kernel.
[ Other Info ]
The patches for focal (apparmor-2.13) can be found at:
https://launchpad.net/~georgiag/+archive/ubuntu/mqueue-sru/
As mentioned before, these patches are already running on apparmor-3.0.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1964636/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
