Mailinglist Archive: opensuse-factory (745 mails)

< Previous Next >
Re: AppArmor changes (was: [opensuse-factory] New Tumbleweed snapshot 20180101 released!)
  • From: Aleksa Sarai <asarai@xxxxxxx>
  • Date: Thu, 4 Jan 2018 10:23:31 +1100
  • Message-id: <20180103232329.k5ys7kbcvyerdolb@gordon>
On 2018-01-04, Aleksa Sarai <asarai@xxxxxxx> 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
< Previous Next >
Follow Ups