In this lesson, you will learn how to use explicit deny rules to enforce strict security boundaries that override broader allow permissions within complex AppArmor profile inheritance chains.
The Power of Explicit Deny
In AppArmor, rules are generally additive: if you have an allow rule anywhere, the profile permits that action. However, security hardening often requires exceptions. What if your application profile inherits a broad allow rule from an abstraction (like base or user-helpers), but you need to ensure a specific, sensitive file remains inaccessible regardless of that inheritance?
This is where the deny keyword becomes essential. A deny rule takes precedence over any allow rule, regardless of where the rule is located in the profile or its included abstractions. It effectively punches a "hole" in your permissive configuration.
Practical Implementation
Imagine you are securing a web server profile that inherits general read access to the /usr/share/ directory via an abstraction. However, you want to strictly prevent access to a specific configuration file containing sensitive API keys located in that same tree.
profile web-server-app /usr/bin/web-server {
# Include broad permissions from an abstraction
include <abstractions/base>
# Inherited allow rule: /usr/share/app/** r,
# Explicitly override the broad allow for this specific file
deny /usr/share/app/config/secret.key r,
# Standard rules remain in effect
/var/www/html/** r,
}
In this snippet, even though the abstractions/base might grant broad read access to /usr/share/app/, the deny rule acts as a mandatory override. If the web server attempts to read secret.key, the kernel will block the access immediately, and the event will be logged as a denial, ignoring the broader allow rule.
This technique is vital when working with complex, nested profiles or when you need to "tighten the screws" on a profile without manually modifying every single included file. It allows you to maintain clean, modular policy structures while ensuring that high-risk resources remain protected from even the most permissive inherited settings.
Key Takeaway: The deny rule acts as a master override, ensuring that specific security restrictions are strictly enforced even if broader allow rules would otherwise grant access.