This section discusses how the SELinux API was implemented in the SELinux security module. Prior to merging SELinux into the mainline Linux 2.6 kernel, the SELinux API was implemented using a security system call multiplexer provided by the LSM kernel patch. However, this security system call was removed by the kernel developers during the Linux 2.5 development series, thereby requiring a reworking of the SELinux API to gain acceptance into mainline Linux. The SELinux API has been refactored into three components: a new /proc/pid/attr API for process attributes, the existing xattr API for file attributes (using a new security namespace), and a selinuxfs pseudo filesystem for the security policy API. Support for the SELinux extensions for System V and socket IPC will be investigated in the future. All three components of the new SELinux API are encapsulated by the libselinux library.
As part of the redesign of the SELinux API for Linux 2.6, SIDs were removed from the API, and only security contexts are now passed by the API calls. This approach provided a better fit with both the /proc-based interface and the xattr-based interface, as well as providing a better fit with the needs of most applications. It also allows for future implementation of kernel tracking of SID usage and safe reclamation of unused SIDs. For applications that would benefit from a SID abstraction, e.g. userspace object managers such as dbusd, nscd, or X, a userspace SID table was implemented in libselinux along with the userspace AVC.
Prior to merging SELinux into mainline Linux 2.6, extended system
calls such as execve_secure
,
open_secure
and stat_secure
were implemented by SELinux to allow security information to be
provided or returned by a call. In the original SELinux kernel patch,
these calls were implemented internally by extending the internal
kernel functions to optionally pass and process SID parameters. This
approach was viewed as enhancing the Linux API to incorporate security
as a first class notion, retaining the original calls for
compatibility but re-implementing them internally by passing default
SIDs to the extended internal functions. Later, in the LSM-based
SELinux, to reduce the invasiveness of SELinux, the calls were
re-implementing by passing SIDs via fields in the task security
structure to and from the security hook functions. However, this
approach of a parallel set of extended calls for existing system calls
was not welcomed by the kernel developers.
Based on kernel developer feedback, the extended system calls of the
original SELinux API were replaced with separate set-attribute calls
that precede an ordinary call. For example, a call to
execve_secure
is replaced with a call to
setexeccon
to set the desired exec security
context followed by a call to execve
to perform
the exec. Similarly, a call to open_secure
or
mkdir_secure
is replaced with a call to
setfscreatecon
to set the desired filesystem
creation context followed by a call to open
or
mkdir
to perform the file creation. The exec
context and fscreate context are attributes of the process like the
umask; if set, they are applied to all subsequent execve or file
creation calls until they are explicitly cleared via
setexeccon
or setfscreatecon
calls with a NULL argument or they are automatically cleared after an
execve (i.e. reset upon each new program execution). Within
libselinux, these calls are implemented via writes to
/proc/self/attr/exec and
/proc/self/attr/fscreate nodes. Note that a
process can only set its own exec and fscreate contexts.
The new SELinux API allows for simplification of applications that merely wish to set a single exec or fscreate context and have it applied for any subsequent execve or file creation call, since the setting of the context can be performed up front and the SID/context does not need to be passed around by the application functions. The API also avoids the need to extend various library functions (e.g. execl*, execv*, popen/pclose, fopen) that internally perform execve or file creation calls, since the caller can simply set the exec or fscreate context prior to making the ordinary library function call and have the context automatically applied when the execve or file creation call is made by the library function.
However, this API does require additional care to be taken by library functions to save and restore the exec or fscreate contexts if they need to set them temporarily for their own processing (e.g. to preserve the security context on /etc/shadow) and by signal handlers to save, reset, and restore these contexts if the signal handler calls execve or a file creation call. The setting of the /proc/pid/attr attributes is not supported for multi-threaded processes.