🔐 Security Enhanced Linux 🔐
Brief intro to SELinux
SELinux (Security-Enhanced Linux) is a security module integrated into the Linux kernel that enforces mandatory access control policies to provide more granular control over how processes and users interact with files and resources. By defining strict rules on what actions each program or user can perform, SELinux significantly enhances the security posture of a Linux system, helping to prevent unauthorized access and exploits.
Brief intro to Apparmor
AppArmor (Application Armor) is a Linux security module that enforces access control policies based on file paths, limiting what resources applications can access to enhance system security. It provides a simpler, profile-based alternative to SELinux, allowing administrators to create restrictive environments for individual applications without requiring deep changes to system configuration.
Key Terminology
Mandatory Access Control – Discretionary Access Control – Security contexts (SELINUX) – SELINUX operating modes -
Comparing AppArmor and SELinux for Container Separation 1
This article provides a brief comparison between SELinux and AppArmor regarding their effectiveness in securely separating containers.
After reading, it became clear that AppArmor is not an ideal choice for DevSecOps when it comes to securely separating containers. This is due to AppArmor's lack of support for Multi-Category Security (MCS). MCS allows for a hierarchy of controls, granting varying levels of access.
Therefore, if you're looking to securely separate containers without relying on Virtual Machines—which can be costly—SELinux emerges as the better option for such tasks.
Key Takeaways 📝
- AppArmor is not label-based, unlike SELinux.
- AppArmor is generally seen as more user-friendly.
- AppArmor has fewer controls compared to SELinux.
- AppArmor has fewer operations available.
- Both support the Type Enforcement security model (a form of mandatory access control).
- The security model is based on rules where subjects (like processes or users) are allowed to access objects (e.g., files, directories, sockets, etc.).
- AppArmor lacks Multi-Level Security (MLS).
- AppArmor does not support Multi-Category Security (MCS).
- 🔄 Because MCS is unavailable, AppArmor cannot maintain proper separation between containers.
- ⚠️ The default container policy in AppArmor is very loose, which could present security risks.
Quick Comparison Table 🔍
| Technology | Type Enforcement | MLS/MCS | Policy Generator | Generator for Containers |
|---|---|---|---|---|
| AppArmor | Yes | No | Yes | No |
| SELinux | Yes | Yes | No* | Yes |
By understanding these differences, it’s clear that SELinux provides a more secure framework for container separation, making it a crucial tool for modern DevSecOps workflows.
Enabling SELinux
Before enabling SELinux, you can verify its current status by running the sestatus command, which provides the Security Enhanced Status of the system. To activate or configure SELinux, you need to modify the configuration file located at /etc/selinux/config. SELinux can operate in two modes:
- Enforcing: SELinux policies are actively enforced, and violations are blocked.
- Permissive: Policies are not enforced, but violations are logged for review, allowing for troubleshooting without blocking actions.
SELinux Contexts
A context in SELinux is a set of security labels used to manage access to files, processes, and other system resources. The context is composed of several fields:
system_u:object_r:httpd_sys_content_t:s0
user:role:type:level
Breakdown of Context Components:
User: Represents the SELinux identity of a subject (process) or object (file). Role: Groups privileges for processes and users, determining what they are allowed to do. Type: Defines how subjects (processes) can interact with objects (files or resources). Level: Used in Multi-Level Security (MLS) or Multi-Category Security (MCS) systems for additional granularity in access control.