Before discussing guidelines on how to use Linux or Unix security features,
it’s useful to know what those features are from a programmer’s viewpoint.
This section briefly describes those features that are widely available
on nearly all Unix-like systems.
However, note that there is considerable variation between
different versions of Unix-like systems, and
not all systems have the abilities described here.
This chapter also notes some extensions or features specific to Linux;
Linux distributions tend to be fairly similar to each other from the
point-of-view of programming for security, because they all use essentially
the same kernel and C library (and the GPL-based licenses encourage rapid
dissemination of any innovations).
It also notes some of the security-relevant differences between different
Unix implementations, but please note that this isn’t an exhaustive list.
This chapter doesn’t discuss issues such as implementations of
mandatory access control (MAC) which many Unix-like systems do not implement.
If you already know what
those features are, please feel free to skip this section.

Many programming guides skim briefly over the security-relevant portions
of Linux or Unix and skip important information.
In particular, they often discuss “how to use” something in general terms
but gloss over the security attributes that affect their use.
Conversely, there’s a great deal of detailed information in
the manual pages about individual functions, but the manual pages
sometimes obscure key security issues with detailed discussions on how
to use each individual function.
This section tries to bridge that gap; it gives an overview of
the security mechanisms in Linux that are likely to be used
by a programmer, but concentrating specifically on the security
ramifications.
This section has more depth than the typical programming guides, focusing
specifically on security-related matters, and points to references
where you can get more details.

First, the basics.
Linux and Unix are
fundamentally divided into two parts: the kernel and “user space”.
Most programs execute in user space (on top of the kernel).
Linux supports the concept of “kernel modules”, which is simply the
ability to dynamically load code into the kernel, but note that it
still has this fundamental division.
Some other systems (such as the HURD) are “microkernel” based systems; they
have a small kernel with more limited functionality, and a set of “user”
programs that implement the lower-level functions traditionally implemented
by the kernel.

Some Unix-like systems have been extensively modified to support
strong security, in particular to support U.S. Department of Defense
requirements for Mandatory Access Control (level B1 or higher).
This version of this book doesn’t cover these systems or issues;
I hope to expand to that in a future version.
More detailed information on some of them is available elsewhere, for
example, details on SGI’s “Trusted IRIX/B”
are available in NSA’s
Final
Evaluation Reports (FERs).

When users log in, their usernames are mapped to integers marking their
“UID” (for “user id”) and the “GID”s (for “group id”) that they
are a member of.
UID 0 is a special privileged user (role) traditionally called “root”;
on most Unix-like systems (including the normal Linux kernel) root
can overrule most security checks and is used to administrate the system.
On some Unix systems, GID 0 is also special and permits unrestricted access
normal to resources at the group level [Gay 2000, 228];
this isn’t true on other systems (such as Linux), but even in those systems
group 0 is essentially all-powerful because so many special system files
are owned by group 0.
Processes are the only “subjects” in terms of security (that is, only
processes are active objects).
Processes can access various data objects, in particular filesystem
objects (FSOs), System V Interprocess Communication (IPC) objects, and
network ports.
Processes can also set signals.
Other security-relevant topics include quotas and limits, libraries,
auditing, and PAM.
The next few subsections detail this.