Tear Down All AppArmor Profiles with aa-teardown

aa-teardown unloads every AppArmor profile on the host in one shot, with no undo and no per-profile option. The examples use it from AppArmor 4.0.1, installed here as package version 4.0.1really4.0.1-0ubuntu0.24.04.7. Allow about ten minutes for the command and checks, plus whatever your services need afterwards.

This is a service-disrupting security operation: running it removes the profiles protecting every currently confined application on the host. You need a root-capable shell and an AppArmor install managed by systemd. Do not reach for it as a routine status check.

1. Understand the one-command contract

Read the help output without changing anything:

$ aa-teardown extra-argument
Usage: /usr/sbin/aa-teardown

Unloads all AppArmor profiles

The extra argument makes it print usage and exit with status 1; the real invocation takes no options and no profile names:

$ aa-teardown

• It runs one thing. On this AppArmor 4.0.1 package, the script calls /lib/apparmor/apparmor.systemd stop.
• It unloads everything. Not one profile, not one application, all of them.
• It keeps no snapshot. There is nothing saved to roll back to afterwards.

$ command -v aa-teardown
/usr/sbin/aa-teardown
$ dpkg-query -W -f='${Package} ${Version}\n' apparmor
apparmor 4.0.1really4.0.1-0ubuntu0.24.04.7

2. Record the current policy state

Inspect the service and profile set before you touch anything. These reads need no sudo:

$ systemctl is-active apparmor.service
active
$ systemctl is-enabled apparmor.service
enabled
$ aa-status --show=profiles

The exact profile listing is host-specific. If aa-status complains that you lack enough privilege, repeat only that check with elevation:

$ sudo aa-status --show=profiles

Save the output in your maintenance notes for an audit trail. An active systemd unit is not the same fact as a useful policy listing: systemd can call a oneshot service active after its load step even when the kernel's profile set is what actually matters.

3. Warn everyone this touches

• The host gets temporarily less protected. Processes that were confined keep running, just without those restrictions. A firewall or Unix permissions might still apply, but neither replaces the profiles you're removing.
• It's not a troubleshooting tool. Don't reach for it to fix one ordinary application failure on production; that's a broad intervention for a narrow problem. Check AppArmor status and logs first, then use a targeted profile-management operation if one exists for your deployment.
• There's no dry run and no profile filter. And pressing Ctrl-C mid-run is not a safe rollback: the underlying stop operation may already have unloaded some profiles by then.

4. Unload everything during the window

Run it with elevated privileges. It takes no arguments:

$ sudo aa-teardown
$ printf 'aa-teardown status: %s\n' "$?"
aa-teardown status: 0

Status 0 means it completed. There's normally no human-readable summary, so don't judge success by whether the terminal printed a list. A non-zero status means it didn't finish as requested: keep the host in its maintenance state and check the service and journal before doing anything else.

5. Verify policy is actually unloaded

Check with privilege, since an unprivileged query may not be able to read the profile set at all:

$ sudo aa-status --show=profiles

On a host with no loaded profiles, expect an empty section or a message saying none are loaded; exact wording depends on your AppArmor utilities and host state. Check the exit status too:

$ sudo aa-status --show=profiles
$ printf 'aa-status status: %s\n' "$?"
aa-status status: 0

If profiles still show up, don't assume teardown was harmless or incomplete. Capture the output, check the service journal, and work out whether another loader or namespace is involved. The manpage promises an all-profile operation, so a leftover profile means investigate the host, not hunt for an extra flag that isn't documented.

6. Restore AppArmor with systemd

Once the maintenance work is done, reload through the installed service:

$ sudo systemctl start apparmor.service
$ systemctl is-active apparmor.service
active
$ sudo aa-status --show=profiles

The local unit is a oneshot loader whose start operation runs AppArmor's reload helper, reading policy under /etc/apparmor.d and loading it. Profile count and names depend on your files and kernel, so compare against your step 2 baseline rather than expecting a fixed list.

If the service won't come up, or profiles don't return, check the unit and journal without changing more state:

$ systemctl status apparmor.service --no-pager
$ sudo journalctl -u apparmor.service -b --no-pager

Common traps

Permission denied: aa-teardown needs authority to stop AppArmor and unload policy. Use sudo for the operation, not as a workaround for not understanding its scope.

You tried to pass a profile name: there's no per-profile mode. Only drop the argument if you genuinely mean to unload everything; otherwise stop and find a tool built for a narrower change.

The service is inactive afterwards: check systemctl status and the journal, then run sudo systemctl start apparmor.service once configuration and kernel support look healthy. Don't leave applications running unprotected while you chase an unrelated problem.

Teardown looks like it did nothing: verify with sudo aa-status --show=profiles, not the service's displayed state. A successful run can produce little or no visible output.