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
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
maintbot accepted review
accepted
maintbot approved review
accepted
jsegitz moved maintenance target to openSUSE:Maintenance:6593
jsegitz accepted request
ok