Overview

Request 483290 accepted

Proposed patch description:

Security update for AppArmor

This update fixes the following security issues in AppArmor:

- preserve unknown profiles when reloading apparmor.service
(CVE-2017-6507, lp#1668892, boo#1029696)
- add aa-remove-unknown utility to unload unknown profiles (lp#1668892)
- migration to apparmor.service turned out to accidently disable AppArmor.
Add a workaround to fix this (boo#1017260 starting at #c7)
Note: This will re-enable AppArmor if it was disabled by the last update.
You'll need to "rcapparmor reload" to actually load the profiles, and then
check aa-status for programs that need to be restarted to apply the profiles.

Additionally, some bugs were fixed:

- fix a crash in aa-logprof on specific change_hat events
- add var.mount dependeny to apparmor.service (boo#1016259#c34)

-----------------------------------------------------------------------------

Note: Both the CVE and accidently disabling AppArmor in the previous update
mean that there could be running processes which lost (or never got) their
AppArmor confinement. Therefore it might be a good idea to set the "reboot
needed" flag in the patch.

FYI, in case you want to improve the text about the CVE:

"rcapparmor reload" unloaded profiles that are not in /etc/apparmor.d/. This
behaviour was fine in the past. However, with containers, virtualization etc.
it became problematic because they often auto-generate profiles and store them
elsewhere - which results in unloading the profile on "rcapparmor reload" and
leaving that container etc. unconfined.

The changes in this update
- no longer unload "unknown" profiles on "rcapparmor reload"
- provide a new tool ("aa-remove-unknown") for admins who explicitely want to
unload unknown profiles

Request History
Christian Boltz's avatar

cboltz created request

Proposed patch description:

Security update for AppArmor

This update fixes the following security issues in AppArmor:

- preserve unknown profiles when reloading apparmor.service
(CVE-2017-6507, lp#1668892, boo#1029696)
- add aa-remove-unknown utility to unload unknown profiles (lp#1668892)
- migration to apparmor.service turned out to accidently disable AppArmor.
Add a workaround to fix this (boo#1017260 starting at #c7)
Note: This will re-enable AppArmor if it was disabled by the last update.
You'll need to "rcapparmor reload" to actually load the profiles, and then
check aa-status for programs that need to be restarted to apply the profiles.

Additionally, some bugs were fixed:

- fix a crash in aa-logprof on specific change_hat events
- add var.mount dependeny to apparmor.service (boo#1016259#c34)

-----------------------------------------------------------------------------

Note: Both the CVE and accidently disabling AppArmor in the previous update
mean that there could be running processes which lost (or never got) their
AppArmor confinement. Therefore it might be a good idea to set the "reboot
needed" flag in the patch.

FYI, in case you want to improve the text about the CVE:

"rcapparmor reload" unloaded profiles that are not in /etc/apparmor.d/. This
behaviour was fine in the past. However, with containers, virtualization etc.
it became problematic because they often auto-generate profiles and store them
elsewhere - which results in unloading the profile on "rcapparmor reload" and
leaving that container etc. unconfined.

The changes in this update
- no longer unload "unknown" profiles on "rcapparmor reload"
- provide a new tool ("aa-remove-unknown") for admins who explicitely want to
unload unknown profiles


Maintenance Bot's avatar

maintbot accepted review

accepted


Maintenance Bot's avatar

maintbot approved review

accepted


Johannes Segitz's avatar

jsegitz moved maintenance target to openSUSE:Maintenance:6593


Johannes Segitz's avatar

jsegitz accepted request

ok

openSUSE Build Service is sponsored by