HP OSMS white paper: Security of Open Source Middleware Stacks

to access control. A secure access control method needs to supersede the controls given to users, including
the root user, and it must enforce MAC, Multi-Level-Security, and even RBAC. Advanced access control
systems, such as SELinux and AppArmor, provide this level of security.
Linux Security Modules
To enable fine-grained access control, eliminate the security issues surrounding the superuser, and provide
MAC, the Linux permission model needed to be replaced. The new system needed to provide MAC, yet
the DAC model found in most POSIX systems needed to remain for backwards compatibility. Additionally,
other security projects needed support to align with the open source community’s commitment to
modularity and diversity, and access control needed to occur at the kernel level for greater security.
The solution for providing modularity is Linux Security Modules (LSM), which creates an agnostic base
of kernel hooks. These hooks enable various access control policies to implement a similar, generic
framework of kernel access control calls.
SELinux
The National Security Agency (NSA) funded research of the Security Enhanced Linux (SELinux ) to provide
security for medium-need systems. SELinux implements the LSM kernel modules and provisions robust
MAC and RBAC controlled systems managed by fine-grained, customizable security profiles.
According to the NSA Security-enhanced Linux Team:
NSA Security-enhanced Linux is a set of patches (now included in the mainline kernel)
to the Linux kernel and some utilities to incorporate a strong, flexible mandatory access
control (MAC) architecture into the major subsystems of the kernel. It provides a
mechanism to enforce the separation of information based on confidentiality and integrity
requirements, which allows threats of tampering and bypassing of application security
mechanisms to be addressed enabling the confinement of damage that can be caused by
malicious or flawed applications. It includes a set of sample security policy configuration
files designed to meet common, general-purpose security goals.
The downside of the SELinux virtually infinite fine-grained permission model is that a complex security
policy is required to manage the system.
For more information, see the NSA SELinux Web site at:
http://www.nsa.gov/selinux/
4
AppArmor
As previously mentioned, the LSM design intentionally creates an agnostic framework, implemented by
various access control designs. SELinux is one such implementation and AppArmor is another. As with
SELinux, AppArmor implements the LSM and enforces MAC through the use of configurable security
policies. AppArmor provides fine-grained control of the system access control.
For more information, see the openSUSE AppArmor Web site at:
http://en.opensuse.org/Apparmor
Comparing AppArmor with SELinux
The main difference between AppArmor and SELinux is the means by which each identifies items at the
atomic level. AppArmor does so by using pathnames, whereas SELinux uses traditional POSIX inodes for
identification. The pathname method provides a more human-friendly description of the items, but it is
vulnerable to a carefully created symbolic link. Although using inodes for unique identification avoids
the symbolic link risk, identifying items with inodes can be overly complex, leading to security holes due
to misconfiguration.
Red Hat currently includes SELinux, while the SUSE Linux distribution provides AppArmor.
The order of complexity for the two LSM implementations is:
1. AppArmor with Pre-defined policy
2. Predefined SELinux policy
4. NSA Security-enhanced Linux Team http://www.nsa.gov/selinux/
Advanced Security 25