4.1 Checking the AppArmor Module Status

An AppArmor module can be in any one of three states:

Unloaded

The AppArmor module is not loaded into the kernel.

Running

The AppArmor module is loaded into the kernel and is enforcing AppArmor program policies.

Stopped

The AppArmor module is loaded into the kernel, but no policies are enforced.

Detect the state of the AppArmor module by inspecting /sys/kernel/security/apparmor/profiles. If cat /sys/kernel/security/apparmor/profiles reports a list of profiles, AppArmor is running. If it is empty and returns nothing, AppArmor is stopped. If the file does not exist, AppArmor is unloaded.

Manage AppArmor through the script rcapparmor, which can perform the following operations:

rcapparmor start

Behavior depends on the AppArmor module state. If it is unloaded, start loads the module and starts it, putting it in the running state. If it is stopped, start causes the module to rescan the AppArmor profiles usually found in /etc/apparmor.d and puts the module in the running state. If the module is already running, start reports a warning and takes no action.

rcapparmor stop

Stops the AppArmor module if it is running by removing all profiles from kernel memory, effectively disabling all access controls, and putting the module into the stopped state. If the AppArmor module is unloaded or already stopped, stop tries to unload the profiles again, but nothing happens.

rcapparmor restart

Causes the AppArmor module to rescan the profiles in /etc/apparmor.d without unconfining running processes. Freshly created profiles are enforced and recently deleted ones are removed from the /etc/apparmor.d directory.

rcapparmor kill

Unconditionally removes the AppArmor module from the kernel. This is unsafe, because unloading modules from the Linux kernel is unsafe. This command is provided only for debugging and emergencies when the module might need to be removed.

WARNING: AppArmor is a powerful access control system and it is possible to lock yourself out of your own machine to the point where you must boot the machine from a rescue medium (such as the first medium of openSUSE) to regain control.

To prevent such a problem, always ensure that you have a running, unconfined, root login on the machine being configured when you restart the AppArmor module. If you damage your system to the point where logins are no longer possible (for example, by breaking the profile associated with the SSH daemon), you can repair the damage using your running root prompt then restart the AppArmor module.