apparmor: Set abi conditionally#13268
Conversation
The "abi" keyword was added for apparmor 3.0 The original change to add this ended up breaking versions < 3.0. The abi itself is a macro in /etc/apparmor.d so we can check if the macro exists to determine if we *can* set an abi in the template. Signed-off-by: Brian Goff <cpuguy83@gmail.com>
There was a problem hiding this comment.
Pull request overview
Updates the AppArmor default profile generator to only emit the abi <...>, directive when the corresponding ABI macro exists on the host, avoiding breakage on AppArmor versions older than 3.0.
Changes:
- Make the template’s
abi <...>,line conditional on a newAbitemplate field. - Detect support by checking for
/etc/apparmor.d/abi/3.0and setAbiaccordingly during template data construction.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
@cpuguy83 if you have time; could you also open a PR in https://github.com/moby/profiles ? |
|
/cherry-pick release/1.7 |
|
@cpuguy83: new pull request created: #13273 DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
@cpuguy83: #13268 failed to apply on top of branch "release/2.0": DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
/cherry-pick release/2.0 release/2.1 release/2.2 |
|
@cpuguy83: new pull request created: #13274 DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
@cpuguy83: #13268 failed to apply on top of branch "release/2.0": DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
@cpuguy83: new pull request created: #13275 DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
@cpuguy83 I think we're missing a cherrypick to 2.0 (seems to have failed the auto-creation). Do you plan to do that manually? |
|
Ah, 2.0 didn't have the original change. |
|
Found another bug by accident; if the current profile is not enforcing (so doesn't have |
containerd 1.7.31 unconditionally emits `abi <abi/3.0>,` as line 2 of its
default AppArmor profile template (see contrib/apparmor/template.go in
v1.7.31). Ubuntu 20.04 (focal) ships AppArmor 2.13.x which does not
understand the `abi <...>,` directive, so every container creation on
focal fails:
AppArmor parser error for /tmp/cri-containerd.apparmor.dXXX at line 2:
Could not open 'abi/3.0': No such file or directory
The regression has already been fixed upstream and backported to the
release/1.7 branch:
- containerd/containerd#13268
- containerd/containerd#13273
so 1.7.32 will work fine on focal again. Rather than hard-pinning focal
to 1.7.30 (which would also have to be bumped manually for every future
1.7.x release), this introduces a `containerd_focal_excluded_versions`
list and selects the latest 1.7.x that is **not** in it. Today that
yields 1.7.30; once 1.7.32 ships it will be picked up automatically and
this workaround can be dropped.
Note: v1.6.6 has already been released with the broken default, so we
intentionally do not rewrite history or roll back any deployments --
existing focal hosts that ended up on 1.7.31 will heal on their next
run once 1.7.32 lands (or by manually overriding
`containerd_focal_excluded_versions`).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
containerd 1.7.31 unconditionally emits `abi <abi/3.0>,` as line 2 of its
default AppArmor profile template (see contrib/apparmor/template.go in
v1.7.31). Ubuntu 20.04 (focal) ships AppArmor 2.13.x which does not
understand the `abi <...>,` directive, so every container creation on
focal fails:
AppArmor parser error for /tmp/cri-containerd.apparmor.dXXX at line 2:
Could not open 'abi/3.0': No such file or directory
The regression has already been fixed upstream and backported to the
release/1.7 branch:
- containerd/containerd#13268
- containerd/containerd#13273
so 1.7.32 will work fine on focal again. Rather than hard-pinning focal
to 1.7.30 (which would also have to be bumped manually for every future
1.7.x release), this introduces a `containerd_focal_excluded_versions`
list and selects the latest 1.7.x that is **not** in it. Today that
yields 1.7.30; once 1.7.32 ships it will be picked up automatically and
this workaround can be dropped.
Note: v1.6.6 has already been released with the broken default, so we
intentionally do not rewrite history or roll back any deployments --
existing focal hosts that ended up on 1.7.31 will heal on their next
run once 1.7.32 lands (or by manually overriding
`containerd_focal_excluded_versions`).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Signed-off-by: ricolin <rlin@vexxhost.com>
containerd 1.7.31 unconditionally emits `abi <abi/3.0>,` as line 2 of its
default AppArmor profile template (see contrib/apparmor/template.go in
v1.7.31). Ubuntu 20.04 (focal) ships AppArmor 2.13.x which does not
understand the `abi <...>,` directive, so every container creation on
focal fails:
AppArmor parser error for /tmp/cri-containerd.apparmor.dXXX at line 2:
Could not open 'abi/3.0': No such file or directory
The regression has already been fixed upstream and backported to the
release/1.7 branch:
- containerd/containerd#13268
- containerd/containerd#13273
so 1.7.32 will work fine on focal again. Rather than hard-pinning focal
to 1.7.30 (which would also have to be bumped manually for every future
1.7.x release), this introduces a `containerd_focal_excluded_versions`
list and selects the latest 1.7.x that is **not** in it. Today that
yields 1.7.30; once 1.7.32 ships it will be picked up automatically and
this workaround can be dropped.
Note: v1.6.6 has already been released with the broken default, so we
intentionally do not rewrite history or roll back any deployments --
existing focal hosts that ended up on 1.7.31 will heal on their next
run once 1.7.32 lands (or by manually overriding
`containerd_focal_excluded_versions`).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Signed-off-by: ricolin <rlin@vexxhost.com>
The "abi" keyword was added for apparmor 3.0
The original change to add this ended up breaking versions < 3.0. The abi itself is a macro in /etc/apparmor.d so we can check if the macro exists to determine if we can set an abi in the template.