Linux Distributed Security Module

Traditionally, the telecom industry has
used clusters to meet its carrier-grade requirements of high
availability, reliability and scalability, while relying on
cost-effective hardware and software. Efficient cluster security is
now an essential requirement that has not yet been addressed in a
coherent fashion.

To answer the need for advanced security features on Linux
clusters in the telecom world, the Open Systems Lab at Ericsson
Research (Montréal, Canada) started a project called
Distributed Security Infrastructure (DSI). The main goal of DSI is
to design and develop a secure infrastructure that provides
advanced security mechanisms for telecom applications running on
carrier-grade Linux clusters. One important component of DSI is the
distributed security module (DSM), which provides an implementation
of mandatory access control within a Linux cluster.

In this article, we discuss the goals of having a distributed
security module, architecture, features, performance and
implementation status. We also offer a tutorial that explains how
to install DSM and experiment with it.

Mandatory Access Control

Currently implemented security mechanisms rely on
discretionary access-control mechanisms. These mechanisms, however,
are inadequate to protect against the various kinds of attacks
possible in today's complex environments. Access decisions are
based on user identity and ownership. As a consequence, these
mechanisms are easy to bypass, and malicious applications easily
can cause failures and breaches in system security.

Various research results have shown that mandatory security
provided by the operating system is essential for the security of
the whole system. Furthermore, they proved that mandatory
access-control mechanisms are efficient for supporting complex
relationships between different entities in the computing
environment.

As part of the DSI Project, we address the design and
implementation of a framework for mandatory access control. We are
implementing cluster-aware access-control mechanisms as a Linux
loadable module. Our work in this area will help position Linux as
a secure operating system for clustered servers.

Our work is based mainly on the Flask architecture and the
Linux security module (LSM) framework; however, our focus is on
Linux clustered servers, not single Linux servers. We address the
performance challenges of the cluster security because enforcing
security may introduce degradation in system performance, an
increase in administration and some annoyance for the user.

One important aspect of our DSM implementation is its
distributed nature. This aspect provides location transparency of
the security resources in the cluster from the security point of
view.

Linux Security Module (LSM)

The LSM framework does not provide any additional security in
the Linux kernel. Rather, it provides the infrastructure to support
the development of security modules. The LSM kernel patch adds
security fields to kernel data structures and inserts calls (called
hooks) at special points in the kernel code to perform a
module-specific access-control check.

LSM adds methods for registering and unregistering security
modules, in addition to a general security system call that allows
communication between user programs and the LSM for security-aware
applications. Each LSM hook is a function pointer in a global
structure called security_ops. Because the hooks are embedded in
the kernel and are called even before a security module is
installed, this structure is initialized to a set of functions
provided by a dummy security module. These functions are simply
placeholders for more useful security mechanisms that can be loaded
as a Linux module. A register_security method is introduced to
allow a security module to set its own security functions to
overlay the dummy functions. An unregister_security method is used
to return to the dummy functions.

The LSM methods are organized into two categories: 1) hooks
to handle the security fields and 2) hooks to perform access
control. When a Linux resource is created, the security label is
attached to it. These labels are used to enforce mandatory access
control with the security hooks. When the object is destroyed, the
label is removed. Hooks to handle the security fields are used for
label creation and removal. An example of those hooks are
alloc_security and free_security in the task_security_ops
structure. The process of mandatory access control using LSM is
presented in Figure 1.

Figure 1. Access Control with LSM Module

Let's assume that the subject (a process in this case) has a
security ID of SSec and is trying to access (1) the resource (a
file in this case) having the security ID TSec. To perform the
access, the subject issues the system call (2). The system call is
handled by the Linux kernel code (the system call interface in
Figure 1). Before the access decision is taken, the kernel consults
(using security hooks) the LSM module (3), where the user-specific
security is implemented as a function “f”. LSM will compute the
function “f” and return the results to the kernel. The kernel
will then either grant or deny access to the target resource
(4).