How Sudo Interacts With AppArmor Profiles In Ubuntu

This guide details the security relationship between the sudo utility and AppArmor mandatory access control in Ubuntu. It examines how AppArmor confines the sudo binary itself and how profiles apply to commands executed with elevated privileges. The explanation covers profile inheritance, execution transitions, and methods to verify confinement status for administrative tasks.

Sudo Confinement

In Ubuntu, the sudo binary often has its own AppArmor profile located at /etc/apparmor.d/usr.bin.sudo. This profile restricts what files and resources the sudo process can access while it is running. It prevents compromised sudo binaries from accessing unauthorized system areas even if executed by a privileged user.

Target Executable Profiles

AppArmor profiles attach to executables, not user IDs. When you run sudo command, the process runs with root UID, but the AppArmor profile depends on the command binary. If the target command has a specific AppArmor profile, that profile enforces restrictions regardless of the root privileges granted by sudo. If the command lacks a profile, it runs unconfined with full root access.

Profile Transitions

AppArmor supports profile transitions during execution. The sudo profile may specify rules for how child processes should be treated. Using flags like px (profile execute) or ix (inherit execute) in the sudo AppArmor configuration, administrators can force specific profiles to load when sudo launches certain programs. This ensures that elevated commands remain confined to expected behaviors.

Verifying Interaction

Users can check the interaction status using AppArmor utilities. The command sudo aa-status displays loaded profiles and processes currently confined. To see if a specific command launched via sudo is confined, check the process list in aa-status while the command is running. If the process appears under a specific profile name, AppArmor is actively restricting its access.