On 2018-01-04, Aleksa Sarai <asarai@suse.de> wrote:
As a complete aside -- there is also currently an AppArmor design flaw, where unloading a profile (ie. restarting the "AppArmor service") will make all previously confined processes unconfined -- with no way for an administrator to re-confine them (other than attaching to each process with GDB and executing aa_changehat from the context of the process).
Is there a reason that restarting the "apparmor service" does anything at all? We really should not be removing profiles automatically given this fairly glaring security problem.
My straw-man pitch would be that "systemctl restart apparmor" should only *replace* profiles that are stored in /etc/apparmor.d. If a profile is not present in /etc/apparmor.d (and *especially* if it's currently confining a process) then the "apparmor service" should not touch it. This could be a good stop-gap until profile removal semantics are fixed in AppArmor. We've had cases where someone has restarted the "apparmor service" and all of their containers are now running with unconfined AppArmor profiles (which is quite bad, given that we know that the AppArmor profiles for Docker containers have protected against kernel 0days in the past). -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/>