| 2022-03-11 19:57:58 |
Stéphane Graber |
bug |
|
|
added bug |
| 2022-03-11 20:15:05 |
Simon Déziel |
bug |
|
|
added subscriber Simon Déziel |
| 2022-03-11 20:35:49 |
Ian Johnson |
snapd (Ubuntu): status |
New |
Incomplete |
|
| 2022-03-12 06:46:10 |
Stéphane Graber |
bug watch added |
|
https://github.com/lxc/lxcfs/issues/522 |
|
| 2022-10-05 07:32:25 |
Andrew Bonney |
bug |
|
|
added subscriber Andrew Bonney |
| 2022-10-06 05:10:31 |
John Johansen |
bug task added |
|
apparmor (Ubuntu) |
|
| 2022-10-06 05:10:54 |
John Johansen |
apparmor (Ubuntu): importance |
Undecided |
High |
|
| 2022-10-06 05:11:03 |
John Johansen |
apparmor (Ubuntu): status |
New |
In Progress |
|
| 2022-11-21 13:21:34 |
Thobias Trevisan |
bug |
|
|
added subscriber Thobias Trevisan |
| 2022-11-23 18:37:45 |
Georgia Garcia |
description |
We've recently noticed a lot of the LXD CI jobs failing because of apparmor related snapd issues.
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
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.
```
Now to break things:
- lxc restart c1
- lxc exec c1 -- distrobuilder
```
root@v1:~# lxc exec c1 -- distrobuilder
cannot change profile for the next exec call: No such file or directory
```
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
capability bpf,
root@c1:~# systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● snapd.apparmor.service loaded failed failed Load AppArmor profiles managed internally by snapd
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.
1 loaded units listed.
```
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
```
One can workaround it with:
```
> /var/lib/snapd/apparmor/snap-confine/cap-bpf
systemctl restart snapd.apparmor.service
```
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? |
[ 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/ |
|
| 2022-11-23 18:38:59 |
Georgia Garcia |
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/ |
[ 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. |
|
| 2022-11-29 09:00:37 |
Rafa |
bug |
|
|
added subscriber Rafa |
| 2022-12-06 10:01:37 |
Łukasz Zemczak |
apparmor (Ubuntu Focal): status |
New |
Fix Committed |
|
| 2022-12-06 10:01:39 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2022-12-06 10:01:40 |
Łukasz Zemczak |
bug |
|
|
added subscriber SRU Verification |
| 2022-12-06 10:01:44 |
Łukasz Zemczak |
tags |
|
verification-needed verification-needed-focal |
|
| 2022-12-12 12:31:28 |
Georgia Garcia |
tags |
verification-needed verification-needed-focal |
verification-done verification-done-focal |
|
| 2023-01-09 13:52:02 |
Heather Lemon |
bug |
|
|
added subscriber Heather Lemon |
| 2023-03-29 00:12:21 |
Launchpad Janitor |
apparmor (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2023-03-29 00:12:34 |
Chris Halse Rogers |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
