SELinux
SELinux (Security-Enhanced Linux), is a part of the Linux security kernel that acts as a protective agent on servers. In the Linux kernel, SELinux relies on mandatory access controls (MAC) that restrict users to rules and policies set by the system administrator. MAC is a higher level of access control than the standard discretionary access control (DAC),and prevents security breaches in the system by only processing necessary files that the administrator pre-approves.
SELinux was initially released as a collaborative between Red Hat and the National Security Agency. SELinux receives periodic updates and additions as new Linux distributions are released. The SELinux kernel separates policy and decisions inside the kernel to distribute levels of protection and prevent a total security breach.
SELinux acts under the least-privilege model. SELinux only grants access if the administrator writes a specific policy to do so.
SELinux modes
There are three modes of SELinux: Enforcing, Permissive and Disabled.
–Enforcing mode – is the default mode at installation of SELinux. It will enforce the policies on the system, deny access and log actions.
–Permissive mode – is the most commonly used mode for troubleshooting SELinux. In this mode, SELinux enables but does not enforce security policies. Also, this means that actions will result in a warning and log for the system administrator.
–Disabled mode – means that SELinux is turned off and the security policies do not protect the server.
AppArmor
AppArmor (Application Armor) is a Linux kernel security module that allows the system administrator to restrict programs’ capabilities with per-program profiles. Profiles can allow capabilities like network access, raw socket access, and the permission to read, write, or execute files on matching paths. AppArmor supplements the traditional Unix discretionary access control (DAC) model by providing mandatory access control (MAC). It has been partially included in the mainline Linux kernel since version 2.6.36 and its development has been supported by Canonical since 2009.
AppArmor and SELinux comparison
There are several key differences:
-One important difference is that AppArmor identifies file system objects by path name instead of inode. This means that, for example, a file that is inaccessible may become accessible under AppArmor when a hard link is created to it, while SELinux would deny access through the newly created hard link.
-SELinux and AppArmor also differ significantly in how they are administered and how they integrate into the system.
-Since it endeavors to recreate traditional DAC controls with MAC-level enforcement, AppArmor’s set of operations is also considerably smaller than those available under most SELinux implementations. For example, AppArmor’s set of operations consist of: read, write, append, execute, lock, and link. Most SELinux implementations will support numbers of operations orders of magnitude more than that. For example, SELinux will usually support those same permissions, but also includes controls for mknod, binding to network sockets, implicit use of POSIX capabilities, loading and unloading kernel modules, various means of accessing shared memory, etc.
-There are no controls in AppArmor for categorically bounding POSIX capabilities. Since the current implementation of capabilities contains no notion of a subject for the operation (only the actor and the operation) it is usually the job of the MAC layer to prevent privileged operations on files outside the actor’s enforced realm of control (i.e. “Sandbox”). AppArmor can prevent its own policy from being altered, and prevent file systems from being mounted/unmounted, but does nothing to prevent users from stepping outside their approved realms of control.
-AppArmor configuration is done using solely regular flat files. SELinux (by default in most implementations) uses a combination of flat files (used by administrators and developers to write human readable policy before it’s compiled) and extended attributes.
-SELinux supports the concept of a “remote policy server” (configurable via /etc/selinux/semanage.conf) as an alternative source for policy configuration. Central management of AppArmor is usually complicated considerably since administrators must decide between configuration deployment tools being run as root (to allow policy updates) or configured manually on each server.