AppArmor Profile Generation

Usage instructions for confining user-space applications through mandatory access control

1. Introduction

This guide explains how to design, generate, and maintain AppArmor profiles in order to confine user-space applications using Mandatory Access Control (MAC).

The focus is on understanding the profile generation workflow, from observation to enforcement, rather than on distribution-specific tooling or automation. The reader is expected to be familiar with Linux process execution, filesystem layouts, and basic security models.

This document is intended for:

System administrators
Power users
Developers running untrusted or semi-trusted applications

The goal is not perfect confinement, but controlled reduction of application capabilities.

2. Scope and non-goals

In scope

AppArmor security model and profile structure
Profile generation through observation and refinement
Enforcing least-privilege policies
Common failure modes and maintenance concerns

Out of scope

SELinux comparisons in depth
Kernel compilation or patching
GUI profile management tools
Container runtimes and orchestration

3. AppArmor security model overview

3.1 Mandatory Access Control

AppArmor enforces access rules independently of user permissions.

Key characteristics:

Policies are enforced by the kernel
Decisions do not depend on UID or GID alone
Denials cannot be bypassed by application logic

MAC is additive to discretionary access control, not a replacement.

3.2 Path-based confinement

Unlike label-based systems, AppArmor uses filesystem paths.

Implications:

Rules match absolute paths
Hard links and path aliases can matter
Mount namespace changes affect policy behavior

This simplifies reasoning but introduces fragility.

3.3 Profiles and execution context

Each confined process:

Is associated with a profile
Inherits confinement across forks
May transition to another profile on execution

Profile attachment is deterministic and explicit.

4. Prerequisites

System requirements

Linux kernel with AppArmor enabled
AppArmor userspace utilities installed
Filesystem paths stable across reboots

Operational requirements

Root access for profile loading
Ability to observe application behavior
Willingness to iterate and refine rules

A test environment is strongly recommended.

5. Profile lifecycle overview

AppArmor profiles typically evolve through four phases:

Discovery
Learning
Enforcement
Maintenance

Skipping phases usually leads to breakage or over-permissive policies.

6. Identifying the confinement target

Before generating a profile, clearly define:

The executable entry point
How the application is launched
Whether it spawns helper binaries
Whether it loads plugins or scripts

Ambiguous execution paths lead to incomplete confinement.

7. Initial profile generation

7.1 Profile skeleton

A minimal profile defines:

The executable path
Basic execution permissions
Default deny behavior

At this stage, the profile is intentionally incomplete.

7.2 Complain (learning) mode

In learning mode:

Access violations are logged
Execution is not blocked
Real behavior can be observed

This mode is essential for dynamic or complex applications.

Learning mode does not guarantee coverage of rare code paths.

8. Observing application behavior

During execution, AppArmor reports:

File reads and writes
Library loading
Network access
Capability usage

Logs reflect what happened, not what is required in all cases.

8.2 Behavioral boundaries

When interpreting logs:

Distinguish core functionality from optional features
Identify transient accesses (temporary files, caches)
Question unexpected network or device access

Not all observed behavior should be allowed.

9. Refining the profile

9.1 Filesystem access

Rules should:

Prefer read-only access where possible
Restrict writable directories
Avoid wildcarding entire trees without justification

Overly broad file rules defeat confinement.

9.2 Execution control

Pay attention to:

Child process execution
Interpreter invocation
Shell escapes

Execution permissions are often the weakest point.

9.3 Capabilities and privileges

Allowing Linux capabilities:

Should be explicit
Must be justified
Is often unnecessary for user-space tools

Capabilities expand the attack surface.

10. Transition to enforce mode

Once the profile is sufficiently refined:

Switch from complain to enforce
Test all expected workflows
Observe for unexpected denials

Enforce mode changes application behavior by design.

11. Handling denials in production

Expected denials

Configuration changes
Plugin additions
Environment variable differences

Unexpected denials

Kernel updates
Path layout changes
Dependency updates

Denials indicate mismatch between policy and reality.

12. Profile maintenance

AppArmor profiles are not static artifacts.

Maintenance requires:

Revisiting profiles after updates
Periodic log review
Pruning unused permissions

Stale rules accumulate silently.

13. Common mistakes and pitfalls

Using broad wildcards to silence denials
Forgetting indirect execution paths
Confining wrapper scripts instead of real binaries
Assuming path-based rules survive refactoring
Treating learning mode output as authoritative

Profiles encode assumptions that must be revisited.

14. Limitations and trade-offs

Strengths

Simple mental model
Low runtime overhead
Good fit for standalone applications

Weaknesses

Path-based fragility
Limited visibility into in-memory behavior
Complex applications require constant tuning

AppArmor improves security posture, not correctness.

15. Variants and alternatives

System-wide confinement

Used for:

Network-facing services
Background daemons

Trade-off:

Higher breakage risk

Per-user applications