Deny-by-exception blacklisting on Linux is a practical, incremental approach to limit risky applications and services while you plan a longer-term deny-by-default (whitelist) strategy required by stronger controls — this post shows how to implement blacklisting safely with AppArmor and how to approach equivalent protections under SELinux for organizations mapping to NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 (CM.L2‑3.4.8).
What Compliance Framework and CM.L2-3.4.8 require in practice
At Level 2 the objective for CM.L2‑3.4.8 is to ensure that systems restrict or remove unnecessary capabilities, services, ports, and software that increase attack surface. For many small businesses the fastest practical control is deny‑by‑exception (blacklist) — selectively denying known risky programs or service paths — while documenting the plan and timeline to move to deny‑by‑default. Implementation notes for compliance: record risk assessments that justify each blacklisted item, capture change control tickets for profile changes, and produce audit evidence (logs, AppArmor status, SELinux labels) demonstrating enforcement.
AppArmor: practical, actionable blacklisting steps
AppArmor is generally easier to use for per‑binary blacklisting because profiles are file‑path based and support explicit deny rules and quick enforcement switching. A compact workflow for a small business: (1) inventory target binaries to block (example: /usr/bin/nmap, /usr/bin/wget in restricted hosts); (2) install apparmor and tools (Debian/Ubuntu: apt install apparmor apparmor-utils; RHEL derivatives may use a different package set); (3) generate a starter profile and run it in complain mode to collect behaviors, then convert to enforce with deny rules.
Example AppArmor commands and profile workflow
Commands you will use: aa-genprof /usr/bin/
SELinux: considerations and practical alternatives
SELinux is a robust Mandatory Access Control (MAC) system but is policy‑centric and more "deny-by-default" in nature — making ad‑hoc blacklisting less straightforward. For organizations running SELinux (for example, RHEL/CentOS/Fedora), practical options are: relabel targeted files with a custom file type and ensure no domain has execute permission for that type; use systemd unit security directives (InaccessiblePaths, ReadOnlyPaths, NoNewPrivileges) to restrict service execution; or use combination controls such as file permissions + secontext changes. Because SELinux policy changes can be delicate, for many small shops the recommended path is: (a) use semanage fcontext -a -t
SELinux example: label a binary and block execution from unconfined domains
Example (conceptual) steps — test in a non‑production host first: semanage fcontext -a -t blacklist_exec_t '/usr/local/bin/badtool'; restorecon -v /usr/local/bin/badtool. Then ensure targeted policy does not include an allow for unconfined_t or relevant domain to execute blacklist_exec_t files. If such an allow exists, remove or adjust it through a carefully created local SELinux module and semodule -i. Because incorrect SELinux policy edits can prevent system boot or service start, always test and maintain rollback procedures.
Real-world scenarios for a small business
Scenario 1: A shared web server should not permit command‑line scanners — identify /usr/bin/nmap and /usr/bin/nikto and create AppArmor profiles to deny network and execute behavior for standard web user processes; document why each binary is blocked and maintain tickets for exceptions. Scenario 2: Developer workstations need limited tools in production — use AppArmor to restrict interpreters (example: block /usr/bin/python3 from executing in /var/www contexts) and use systemd service hardening to limit services' file visibility. Scenario 3: Remote jump hosts — combine SELinux file relabeling and AppArmor per‑service profiles to prevent tools that can pivot (ssh tunnels, port scanners) while logging any denial for auditing.
Compliance tips, logging, and best practices
1) Document every blacklisted item with the risk justification and planned review date; blacklisting should be temporary when possible and accompanied by a roadmap toward whitelist controls. 2) Maintain test, staging, and production profiles; deploy to production only after controlled testing. 3) Capture and retain logs (AppArmor denials in syslog/journal and SELinux AVCs in audit.log) as evidence for auditors; annotate logs with change ticket IDs. 4) Integrate profile changes into configuration management (Ansible/Chef/Puppet) so profiles are versioned and reproducible. 5) Avoid making broad "deny all" changes without fallbacks — misconfigured profile can break monitoring or backups. 6) Schedule periodic reviews (quarterly) to tune profiles as legitimate usage changes.
Risk of not implementing deny‑by‑exception or equivalent controls
If you do not restrict risky binaries and services you leave systems exposed to lateral movement, reconnaissance, and data exfiltration. Attackers often rely on preinstalled tools (curl/wget/python) or well‑known scanner binaries to discover vulnerabilities and stage attacks; lack of controls makes incident containment slower and increases the probability of CUI compromise — which is directly relevant to NIST SP 800‑171/CMMC obligations and can result in contract loss or remediation orders.
In summary, for NIST SP 800‑171 Rev.2 / CMMC 2.0 Level 2 (CM.L2‑3.4.8) environments, AppArmor offers a pragmatic route to implement deny‑by‑exception blacklisting quickly and with clear audit evidence; SELinux can provide equivalent or stronger protections but requires careful policy work and testing. Regardless of the mechanism, pair technical controls with documented risk decisions, change control, testing, and log collection — and maintain a roadmap to a deny‑by‑default (whitelist) posture where feasible.
