Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 81

SELinux/AppArmor: Status & Troubleshooting Policy Denials

Recommended resources

Hello! Welcome back.

In our last lesson, we introduced the theoretical concepts behind Mandatory Access Control (MAC), contrasting it with the standard Linux permissions you're already familiar with. We established that SELinux (label-based) and AppArmor (path-based) add a crucial security layer to confine applications and limit the damage from a potential compromise.

Now, we move from theory to one of the most practical and essential skills for a Linux administrator: troubleshooting. Both SELinux and AppArmor are notorious for causing "permission denied" errors that can be baffling if you don't know where to look. This lesson will equip you to handle these situations by teaching you how to check SELinux/AppArmor status and interpret policy denial logs for troubleshooting. By the end of this lesson, you'll know exactly what to do when an application misbehaves and you suspect a MAC policy is the culprit.

1. Troubleshooting SELinux

As we discussed, SELinux is the default MAC on Red Hat-based systems (like RHEL, CentOS, Fedora). Its system-wide, label-based approach is powerful but can be complex.

Checking SELinux Status and Mode

The first step in any troubleshooting scenario is to determine if SELinux is active and, if so, in which mode it's operating.

  • Enforcing: The default and most secure mode. SELinux actively blocks any action that violates its policy.
  • Permissive: SELinux does not block actions, but it records any policy violations in its log file. This is an invaluable mode for troubleshooting.
  • Disabled: SELinux is completely turned off. This is generally discouraged and requires a system reboot to change.

I Hate SELinux. You Can Too. (Linux+ Objective 2.5.1)

To see how to check and change these modes in practice, let's turn to the video "I Hate SELinux. You Can Too." by Shawn Powers. This segment clearly demonstrates the key commands.

Watch from 01:58 to 05:56. Pay close attention to the distinction between getenforce (quick check), sestatus (detailed view), and how to change the mode temporarily with setenforce versus permanently in the /etc/selinux/config file.

To summarize the key commands:

  • getenforce: Instantly tells you if the mode is Enforcing, Permissive, or Disabled.
  • sestatus: Provides a detailed report, including the current mode, the mode set in the configuration file, and the policy name.
SELinux Status Output (sestatus command)
Output of the `sestatus` command, showing that SELinux is enabled, the policy name, and that the current mode is 'permissive', even though the configuration file is set to 'enforcing'. This demonstrates the difference between the runtime state and the permanent configuration.

Finding and Interpreting SELinux Denial Logs

When SELinux in Enforcing mode blocks an action, it logs an Access Vector Cache (AVC) denial. Your job is to find and understand this denial log.

SELinux in RHEL 10 Explained for Beginners

The raw logs can be cryptic. Fortunately, RHEL-based systems provide excellent tools to make sense of them. This article, "SELinux in RHEL 10 Explained for Beginners", provides a great overview of the tools and the process.

First, read the section titled 'Troubleshooting SELinux Denials' for a high-level workflow. Then, refer to the 'Tools to Manage SELinux in RHEL 10' section to learn the names of the key troubleshooting utilities like ausearch, audit2why, and sealert.

The troubleshooting workflow generally looks like this:

  1. Confirm SELinux is the Cause: You see a "Permission denied" error, but standard file permissions (ls -l) look correct. You run getenforce and see Enforcing.
  2. Find the Log Entry: SELinux logs are stored in /var/log/audit/audit.log. You can search for recent AVC denials using ausearch -m avc -ts recent.
  3. Translate the Log: The most powerful step is to use a tool to interpret the cryptic log entry. The setroubleshoot package provides a fantastic utility called sealert.

Let's look at sealert in action.

Interpreting SELinux Audit Logs with sealert
This is the output of `sealert` analyzing the audit log. It has detected a denial and is not only explaining what was blocked (qemu-ga trying to read authorized_keys) but also providing concrete, copy-pasteable commands (`setsebool -P ...`) to resolve the issue by changing an SELinux boolean.

As the image shows, sealert -a /var/log/audit/audit.log analyzes the log file and gives you a human-readable explanation and one or more suggested fixes. This is the primary tool for interpreting SELinux denials.

A Common SELinux Problem: Mislabeled Files

The most common SELinux issue arises from its label-based nature. As we learned, moving a file (mv) preserves its original context, while copying (cp) gives the new file the context of its destination.

I Hate SELinux. You Can Too. (Linux+ Objective 2.5.1)

Let's watch a classic demonstration of this problem and how to fix it.

Watch from 11:03 to 15:58. This segment shows how a moved file fails to be served by a web server due to its incorrect context, while a copied file works. Then, it demonstrates how to use restorecon to fix the incorrect label, which is the standard solution for mislabeled files.

The key takeaway is the command restorecon. If you suspect a file has the wrong SELinux context (which you can check with ls -Z), restorecon will read the system's default policies and restore the correct context to the file or directory.

  • restorecon /path/to/file fixes a single file.
  • restorecon -R /path/to/directory recursively fixes an entire directory.

2. Troubleshooting AppArmor

Now let's switch to AppArmor, the path-based MAC found on Debian-based systems like Ubuntu and on SUSE. Its application-focused profiles make it conceptually simpler to troubleshoot.

Checking AppArmor Status

Like SELinux, AppArmor profiles for applications can be in different modes:

  • Enforce: Rules are actively enforced.
  • Complain: Violations are logged, but not blocked. Ideal for developing or debugging a profile.
  • Disabled: The profile is not loaded into the kernel and provides no protection.

AppArmor Sucks Less! (Linux+ Objective 2.5.2)

The video "AppArmor Sucks Less!" gives a concise overview of AppArmor's modes and the primary command for checking its status.

Watch from 07:22 to 09:45. This explains the three main modes and demonstrates the aa-status command, which is your central hub for seeing what AppArmor is doing on your system.

The command sudo aa-status (or the older sudo apparmor_status) gives you a complete picture, listing:

  • How many profiles are loaded.
  • Which profiles are in enforce mode.
  • Which profiles are in complain mode.
  • Which processes are currently being confined.

Finding and Interpreting AppArmor Denial Logs

The AppArmor troubleshooting workflow is more interactive than SELinux's. The goal is often to generate logs of what an application needs to do and then use a tool to approve those actions.

Ubuntu Security Reinvented: Hardening Your System with AppArmor

This article from Linux Journal clearly outlines the commands for finding logs and the primary tool used to interpret them.

Read the section 'Troubleshooting and Log Analysis'. It shows you how to find AppArmor denial messages in the system logs and introduces the aa-logprof tool.

The workflow is as follows:

  1. Identify the Misbehaving App: An application is failing. You run sudo aa-status and see it has a profile in enforce mode.
  2. Switch to Complain Mode: You put the application's profile into complain mode so it can run without being blocked, while still logging everything it tries to do. Example: sudo aa-complain /usr/sbin/sshd.
  3. Generate Logs: You use the application and perform the actions that were previously failing.
  4. Update the Profile: You run sudo aa-logprof. This tool scans the logs for apparmor="DENIED" messages and interactively prompts you to (A)llow, (D)eny, or (I)gnore each action, automatically updating the profile file for you.
  5. Re-enforce the Profile: Once you've updated the profile, you switch it back to enforce mode: sudo aa-enforce /usr/sbin/sshd.

AppArmor Sucks Less! (Linux+ Objective 2.5.2)

This process is best understood by seeing it in action. Let's watch as a new, empty profile for the ss command is created and then populated using aa-logprof.

Watch from 15:36 to 19:11. This segment perfectly demonstrates the complain-log-update cycle. You'll see the command fail, and then aa-logprof is used to read the logs and interactively build the correct rules to allow it to function.

This interactive workflow with aa-logprof is the core of AppArmor troubleshooting and a key skill for the Linux+ exam.

Test your understanding!

You've just installed a new web application on an Ubuntu server. When you try to access it, you get an error. The logs show the application is being denied access to /var/log/webapp/error.log. You run sudo aa-status and see the web application has a profile in enforce mode.

What is the most appropriate sequence of commands to resolve this issue?

  1. sudo aa-enforce /path/to/profile
  2. sudo aa-complain /path/to/profile
  3. sudo aa-logprof
Show answer

The correct sequence is 2, 3, 1.

  1. sudo aa-complain /path/to/profile: First, you put the profile into complain mode. This allows the application to run and write to its log file, while AppArmor records the "denied" action.
  2. sudo aa-logprof: Next, you run this tool to scan the logs. It will find the denial for /var/log/webapp/error.log and ask you if you want to allow it. You would choose to allow it, and aa-logprof would update the profile.
  3. sudo aa-enforce /path/to/profile: Finally, with the profile updated, you switch it back to enforce mode to secure the application.

Conclusion

You now possess the fundamental skills to diagnose and begin resolving issues caused by the two major Mandatory Access Control systems on Linux. This knowledge transforms SELinux and AppArmor from mysterious sources of frustration into manageable and powerful security tools.

Key Takeaways:

  • When permissions seem correct but access is denied, always suspect the MAC system.
  • For SELinux (Red Hat-based):
    • Check status with getenforce and sestatus.
    • Find recent denials with ausearch -m avc -ts recent.
    • Interpret denials with sealert -a /var/log/audit/audit.log.
    • Fix mislabeled files (a very common issue) with restorecon.
  • For AppArmor (Debian/SUSE-based):
    • Check status with sudo aa-status.
    • Troubleshoot using the complain-log-update cycle.
    • Switch modes with aa-complain and aa-enforce.
    • Update profiles based on logs with aa-logprof.

Preview of the Next Lesson:
We've now hardened our system at the network level (firewalld) and the application level (MAC). In the next lesson, we will go one level deeper to focus on the storage itself. We will learn how to harden filesystems by setting appropriate mount options in /etc/fstab, preventing common risks like unwanted program execution or device access from mounted drives.