Introduction to AppArmor and SELinux on Linux

As cybersecurity threats grow more sophisticated, ensuring the security of your Linux system is critical. Among the arsenal of tools available for enhancing Linux security, AppArmor and SELinux are two of the most powerful. These Mandatory Access Control (MAC) systems provide an additional layer of protection by restricting how applications can interact with the system. In this guide, we will explore Introduction to AppArmor and SELinux on Linux, understand their differences, and provide a comprehensive technical tutorial on how to implement and manage them on your Linux systems. This article aims to provide a comprehensive introduction to Introduction to AppArmor and SELinux on Linux for both beginners and experienced system administrators.

Understanding AppArmor

AppArmor (Application Armor) is a security module for the Linux kernel that allows the system administrator to restrict the capabilities of individual programs. AppArmor uses security profiles to determine what resources applications can access, thus limiting potential damage from malicious code. Let’s dive deeper into Introduction to AppArmor and SELinux on Linux.

How AppArmor Works

AppArmor works by associating each program with a security profile that specifies its permissions. These profiles can define what files an application can read, write, or execute. AppArmor operates in two modes:

• Enforce Mode: AppArmor actively enforces the restrictions defined in the profile. Any action not explicitly allowed is denied and logged.
• Complain Mode: AppArmor does not enforce the restrictions but logs any actions that would have been denied. This mode is useful for testing and refining profiles before putting them into enforce mode.

AppArmor Profiles

AppArmor profiles are plain text files that define the access rights for applications. These profiles can be set to allow or deny specific actions on files, directories, or even system resources like network access.

Example of an AppArmor Profile

#include <tunables/global>
/usr/sbin/apache2 {
  #include <abstractions/base>
  /var/www/html/** r,
  /etc/apache2/** r,
  /usr/sbin/apache2 mr,
  capability net_bind_service,
  network inet tcp,
}

In the above profile, Apache is granted read access to /var/www/html/, /etc/apache2/, and memory-read (mr) access to its binary. Additionally, it is allowed to bind to a network service via the capability net_bind_service and interact with the TCP network stack.

Getting Started with AppArmor on Linux

Installing AppArmor

AppArmor is available on most Linux distributions, but it may need to be installed and enabled. On Ubuntu, for example, it’s usually installed by default. However, if you need to install it, you can do so with the following commands:

$ sudo apt-get update
$ sudo apt-get install apparmor apparmor-utils

Enabling and Disabling AppArmor

To check if AppArmor is enabled, use:

$ sudo aa-status

To enable AppArmor, you can modify the GRUB configuration. Edit /etc/default/grub and add apparmor=1 security=apparmor to the GRUB_CMDLINE_LINUX_DEFAULT line:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash apparmor=1 security=apparmor"

Then update GRUB:

$ sudo update-grub
$ sudo reboot

To disable AppArmor, simply remove or comment out the apparmor=1 security=apparmor line from the GRUB configuration and reboot.

Managing AppArmor Profiles

AppArmor profiles are stored in /etc/apparmor.d/. You can create, modify, or delete profiles based on your requirements.

Creating a New AppArmor Profile

To create a new profile, you can use the aa-genprof tool. For example, to create a profile for the /usr/bin/evince application:

$ sudo aa-genprof /usr/bin/evince

Follow the on-screen instructions to specify permissions as the application runs.

Setting a Profile to Enforce Mode

Once a profile is created, you can set it to enforce mode:

$ sudo aa-enforce /etc/apparmor.d/usr.bin.evince

This command ensures that the profile is actively enforcing its rules.

Setting a Profile to Complain Mode

If you prefer to test a profile before enforcement:

$ sudo aa-complain /etc/apparmor.d/usr.bin.evince

In this mode, AppArmor will log any violations without enforcing the restrictions.

Understanding SELinux

Security-Enhanced Linux (SELinux) is another MAC framework that controls access to files, processes, and network resources based on security policies. Originally developed by the NSA, SELinux is known for its fine-grained security control, making it suitable for highly sensitive environments.

How SELinux Works

SELinux operates by labeling files, processes, and other system resources with a context. Policies then define what actions are allowed based on these contexts. SELinux can operate in three different modes:

• Enforcing: SELinux actively enforces the security policies. Any action not explicitly allowed is denied and logged.
• Permissive: SELinux does not enforce the policies but logs any actions that would have been denied.
• Disabled: SELinux is completely disabled and does not provide any security features.

SELinux Policies

SELinux policies are comprehensive rulesets that define the access permissions for all subjects and objects in the system. Policies are usually divided into two categories:

• Targeted Policy: This is the most common policy, which targets specific processes and services for protection.
• MLS (Multi-Level Security) Policy: This policy is used in highly secure environments and provides very fine-grained access control based on security levels.

Example of an SELinux Policy

allow httpd_t httpd_sys_content_t:file { read open getattr };

In this policy snippet, the httpd_t domain (typically associated with the Apache server) is allowed to read, open, and get attributes of files labeled with the httpd_sys_content_t type.

Getting Started with SELinux on Linux

Installing SELinux

On most distributions like CentOS, RHEL, and Fedora, SELinux is installed and enabled by default. For Debian-based systems like Ubuntu, it can be installed as follows:

$ sudo apt-get install selinux-basics selinux-policy-default auditd
$ sudo selinux-activate
$ sudo reboot

Configuring SELinux Modes

You can check the current mode of SELinux using the sestatus command:

$ sestatus

To change the mode of SELinux, edit the /etc/selinux/config file:

SELINUX=enforcing

The available options are:

• enforcing: SELinux is enabled and enforcing its policies.
• permissive: SELinux is enabled but only logging policy violations.
• disabled: SELinux is completely disabled.

After making changes, reboot the system for them to take effect.

$ sudo reboot

Managing SELinux Policies

SELinux policies are stored in /etc/selinux/ and can be managed using various tools like semanage, setsebool, and audit2allow.

Creating a New SELinux Policy Module

To create a custom policy module, follow these steps:

1. Create a Type Enforcement (TE) file:

module mymodule 1.0;
require {
  type httpd_t;
  type myapp_exec_t;
}
allow httpd_t myapp_exec_t:file execute;

2. Compile the policy:

$ checkmodule -M -m -o mymodule.mod mymodule.te
$ semodule_package -o mymodule.pp -m mymodule.mod

3. Install the policy:

$ sudo semodule -i mymodule.pp

This will load the custom policy into the active SELinux policy.

Managing SELinux Booleans

SELinux Booleans allow you to toggle specific policies on and off. You can list all available Booleans with:

$ sudo getsebool -a

To change a Boolean value, use the setsebool command:

$ sudo setsebool httpd_can_network_connect on

To make this change permanent, add the -P option:

$ sudo setsebool -P httpd_can_network_connect on

AppArmor vs. SELinux: Key Differences

While both AppArmor and SELinux provide MAC security, they have significant differences that affect their use cases and management. Understanding Introduction to AppArmor and SELinux on Linux requires appreciating these distinctions.

Profile-Based vs. Label-Based

AppArmor uses profile-based controls, where individual profiles are created for each application. These profiles define what resources the application can access. SELinux, on the other hand, is label-based, where every file, process, and resource is labeled with a security context. Policies are then applied based on these labels.

Ease of Use

AppArmor is often considered easier to use due to its straightforward profile system, which requires less in-depth knowledge to create and manage. SELinux, while more powerful, has a steeper learning curve due to its complex policy and labeling system.

Default Availability

AppArmor is the default MAC system on Ubuntu and some other Debian-based distributions. SELinux is the default on Red Hat-based distributions like CentOS, Fedora, and RHEL.

Granularity of Control

SELinux offers finer-grained control compared to AppArmor. This makes it suitable for environments where security is of utmost importance, such as government or enterprise systems. AppArmor, while effective, does not offer the same level of detailed control.

Use Cases for AppArmor and SELinux

The choice between AppArmor and SELinux often depends on the specific requirements of your environment.

When to Use AppArmor

• Ease of Implementation: When you need a security solution that is relatively easy to set up and manage.
• Application-Specific Restrictions: When you want to restrict the capabilities of specific applications without affecting the entire system.
• Container Security: For securing Docker containers and other containerized environments.

When to Use SELinux

• High-Security Environments: When you require a very fine-grained and comprehensive security solution.
• Compliance Requirements: When you need to comply with security standards that mandate strong MAC controls.
• System-Wide Security: When you want to enforce security policies across the entire system, including files, processes, and network resources.

Advanced Configuration and Tuning

Both AppArmor and SELinux can be fine-tuned to meet specific security requirements. This section will cover advanced configuration techniques for both tools.

Advanced AppArmor Configuration

Using AppArmor with Containers

AppArmor can be particularly useful in securing containerized environments. For example, you can assign specific profiles to Docker containers to restrict their capabilities.

$ docker run --rm -it --security-opt apparmor=docker-default ubuntu

This command runs a Docker container with the docker-default AppArmor profile, restricting the container’s access to the host system.

Debugging AppArmor

To debug AppArmor profiles, you can use the aa-logprof tool, which helps in analyzing logs and updating profiles:

$ sudo aa-logprof

This tool will parse the logs and suggest updates to existing profiles based on the logged events.

Advanced SELinux Configuration

Customizing SELinux Labels

Custom labels can be created and applied to files or processes to enforce specific policies. For example, to create a custom label:

$ sudo semanage fcontext -a -t my_custom_t "/custom/path(/.*)?"
$ sudo restorecon -Rv /custom/path

Here, the semanage command defines a custom file context for the specified path, and restorecon applies the new label.

SELinux in Virtualized Environments

SELinux can be particularly beneficial in virtualized environments where security isolation is critical. For instance, you can apply specific SELinux policies to virtual machines to control their access to host resources.

$ sudo virsh setsebool virt_use_execmem on

This command enables the virt_use_execmem Boolean, allowing virtual machines to execute in-memory code, which is essential for certain workloads.

Troubleshooting and Common Issues

Both AppArmor and SELinux come with their set of challenges. This section will address common issues and how to resolve them.

Common Issues with AppArmor

• Application Not Working After Applying Profile: If an application stops working after applying an AppArmor profile, it is likely that the profile is too restrictive. Try setting the profile to complain mode to identify the denied actions and update the profile accordingly.

$ sudo aa-complain /etc/apparmor.d/usr.sbin.mysqld

• Profile Conflicts: Conflicting profiles can cause unexpected behavior. Ensure that profiles do not overlap or contradict each other.

Common Issues with SELinux

• Application Not Working Due to Policy Restrictions: If an application is not working due to SELinux, check the audit logs to identify the denied actions. Use the audit2allow tool to create custom policies to allow the necessary actions.

$ sudo cat /var/log/audit/audit.log | audit2why

• Incorrect Labels: Incorrect labels on files or directories can cause access denials. Use the restorecon command to reset the labels to their default values.

• Temporary Workaround: If you are unsure how to fix an SELinux issue immediately, you can temporarily set SELinux to permissive mode:

$ sudo setenforce 0

FAQs

What is the difference between AppArmor and SELinux?
AppArmor uses a profile-based approach to define security policies for applications, while SELinux uses a label-based system to enforce policies across the entire system.

Is AppArmor easier to use than SELinux?
Yes, AppArmor is generally considered easier to use because it requires less in-depth knowledge to create and manage profiles compared to SELinux’s more complex policy system.

Can I run both AppArmor and SELinux on the same system?
While it’s technically possible to have both installed, it’s not recommended to run both simultaneously as they can conflict with each other. Most systems use one or the other.

How do I switch between enforcing and permissive modes in SELinux?
You can switch modes using the setenforce command. Use setenforce 1 for enforcing mode and setenforce 0 for permissive mode.

Is it necessary to reboot the system after installing SELinux?
Yes, after installing and activating SELinux, a reboot is necessary to apply the security contexts to the system files.

Can AppArmor be used to secure Docker containers?
Yes, AppArmor can secure Docker containers by applying specific profiles that restrict the container’s capabilities.

Conclusion

AppArmor and SELinux are powerful tools in the Linux security toolkit, each offering unique advantages. AppArmor provides a more user-friendly approach with its profile-based system, making it ideal for less complex environments. SELinux, with its fine-grained control and comprehensive policy enforcement, is suited for high-security environments where stringent access controls are necessary. By understanding and properly configuring these tools, you can significantly enhance the security of your Linux systems. Introduction to AppArmor and SELinux on Linux is a fundamental aspect of securing modern Linux environments.

Alternative Solutions to Enhancing Linux Security

While AppArmor and SELinux are powerful MAC systems, alternative or complementary approaches exist to enhance Linux security. Here are two different ways to solve the problem of application confinement and system hardening:

1. Using Namespaces and Capabilities

Linux namespaces provide process isolation by virtualizing system resources like process IDs (PIDs), network interfaces, mount points, and inter-process communication (IPC). Combined with Linux capabilities, which allow fine-grained control over privileged operations, this approach offers a lighter-weight alternative to MAC systems for application confinement.

Explanation:

• Namespaces: Isolate processes, preventing them from seeing or affecting resources in other namespaces. This isolates applications from each other and the host system.
• Capabilities: Break down the traditional root/non-root privilege model into smaller units. Instead of granting a process full root privileges, capabilities allow it to perform only specific privileged operations.

Code Example:

Using unshare to create a new namespace and drop capabilities:

# Create a new PID namespace
sudo unshare -p --fork --mount-proc

# Drop capabilities
sudo setcap cap_net_bind_service,cap_net_raw=-ep /path/to/your/application

# Execute the application in the isolated environment
sudo chroot /path/to/rootfs /path/to/your/application

Explanation of Commands:

• unshare -p --fork --mount-proc: Creates a new PID namespace and mounts the proc filesystem.
• setcap cap_net_bind_service,cap_net_raw=-ep /path/to/your/application: Removes cap_net_bind_service and cap_net_raw from the effective and permitted capability sets of the application.
• chroot /path/to/rootfs /path/to/your/application: Changes the root directory for the current process and its children, further isolating the application to a specific directory.

This approach is often used in containerization technologies like Docker, where each container runs in its own set of namespaces and with limited capabilities.

2. Using System Call Filtering (seccomp)

seccomp (secure computing mode) is a Linux kernel feature that allows a process to restrict the system calls it can make. This approach provides a strong defense against exploits that rely on calling specific system calls to compromise a system.

Explanation:

• System Call Filtering: By limiting the set of system calls an application can make, you can significantly reduce the attack surface. Even if an attacker gains control of the application, they will be limited by the restricted set of available system calls.

Code Example:

Using libseccomp to filter system calls in a C application:

#include <seccomp.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>

int main(int argc, char *argv[]) {
    scmp_filter_ctx ctx;

    // Initialize seccomp context
    ctx = seccomp_init(SCMP_ACT_KILL); // Kill process on disallowed syscall

    // Allow essential system calls
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(read), 0);
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(write), 0);
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(exit), 0);
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(fstat), 0);
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(brk), 0);
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(mmap), 0);
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(munmap), 0);
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(close), 0);

    // Load the filter
    int rc = seccomp_load(ctx);
    if (rc < 0) {
        perror("seccomp_load");
        seccomp_release(ctx);
        return EXIT_FAILURE;
    }

    seccomp_release(ctx);

    // Your application logic here
    printf("Hello, seccomp!n");

    return EXIT_SUCCESS;
}

Explanation:

1. Initialize seccomp context: seccomp_init(SCMP_ACT_KILL) sets up the seccomp context to kill the process if a disallowed system call is made.
2. Allow essential system calls: seccomp_rule_add allows specific system calls that the application needs to function. Example SCMP_SYS(read), SCMP_SYS(write), etc.
3. Load the filter: seccomp_load(ctx) loads the filter into the kernel, enforcing the restrictions.
4. Release the context: seccomp_release(ctx) releases the seccomp context.

This method requires modifying the application code to include the libseccomp library and define the allowed system calls. It provides a very precise way to limit the capabilities of an application and protect the system from exploits. Tools like Docker also leverage seccomp to enhance container security.