Promoting Linux Requires Advertising. That's What Counts.
Linux Security Systems and Tools
Computer Security is a wide and deep topic. There are many different
aspects of computer security, ranging from encryption to authentication,
from firewalls to intrusion detection systems, from virtual machines
to trust and capabilities systems. Only the last few subtopics are
covered on this page; the former are well-known and there are many
generally available references.
The topic of security in general also has some very interesting moral,
ethical and legal repercussions. Strong security systems often provide
strong protections of individual and corporate privacy. Strong guarantees
of privacy allow criminals to hide from police and governments, as
well as allowing innocent, upstanding individuals and organizations
to hide from crooked policemen and corrupt governments. Examples abound:
from Oliver North to Columbian drug cartels, from
dissidents in China
to Al Queda. The tools that keep out viruses, worms and crackers
can also help keep out other, far more dangerous intruders.
- Encryption is a set of techniques and mathematical formulas used
to encode, hide and make unreadable files and network communications.
Examples include SSL, ssh and IPSEC. Encryption often concerns the
hiding of not only the communications, but also the identity
of the sender, thus techniques like anonymous remailers
fall in this category. Many interesting technologies, including
digital money and encrypted P2P file sharing systems are made
possible or advanced thanks to encryption algorithms.
- Authentication concerns the means by which one can verify that a
user (a person, a computer user, or typically another computer
program) is who they claim to be, rather than an imposter, fraudster
or spy. Password systems, PAM, PGP/GPG and kerberos are all
- Firewalls are network packet filters that are capable of blocking
unwanted network traffic, while passing through allowed traffic.
Firewalls are often the first line of defense against crackers
and Internet worms, which can be blocked by denying the means
of network ingress.
- Spam Filters
- Spam filters are a special case of content-based blocking: when
network traffic takes a particular form (such as unsolicited email
advertising), it is blocked or discarded.
- Intrusion Detection Systems
- Intrusion Detection Systems (IDS'es) attempt to determine when
a cracker is trying to break into a system, or has broken into
a system, and give the system administrator warning the a breakin
is imminent or has occurred. IDS's can watch for inappropriate
network traffic going to inappropriate ports (e.g. SNORT),
unexpected file modifications (e.g. TripWire) or inappropriate
system calls (e.g. Remus).
- Honeypots are intentionally insecure computer systems to attract
crackers like flies to honey, where their actions, behaviors and
techniques can be observed.
- Hypervisors/Virtual Machines (VM's)
- Hypervisors and virtual machines are computers-within-computers.
These are typically software systems, sometimes supported with
custom hardware, that can make it appear as if there were multiple
computers that are running when in fact there is only one
physical hardware computer. Typically users of one virtual
machine (VM) aren't aware that there are other VM's and thus,
if they break into one VM, cannot (in theory) get to the other
VM's. A general example is the JVM (Java Virtual Machine).
Linux-kernel specific examples are
vmware (on x86),
Bochs (a full PC emulator),
UML User-Mode-Linux (run multiple kernels).
Although VM's are theoretically secure, they can be broken
in many ways. One interesting one I've heard of recently
is for breaking smart-card VM's: one downloads
a huge number of jump instructions to the cracker code
into unprotected memory,
and then attempts to cause an instruction addressing error
by e.g. heating the card, so as to branch control to
the downloaded code. Bingo .. you've broken out of the
- ERights/Capability Systems
- Capability systems define a set of actions that can be
performed, and then associate a permission bit indicating
whether a given process is 'capable' of performing that
action. A capability does not (normally) make reference to
a particular object (e.g. to a particular file);
rather it indicates whether a process can do a certain
thing in general. For example, in traditional Unix,
the root user is capable of doing all sysadmin tasks:
the root user can change the ownership of files, or
bind IP addresses to network interfaces. But if the
CAP_CHOWN capability is taken away from root, then
the root user would no longer be able to change file
ownerships, while still having full control over
network operations. If capabilites are used widely,
a good sysadmin can delegate e.g. the network admin
functions without worrying that the newbie admin will
scramble the filesystem.
To get a useful security system, one must
augment capabilities with some sort of access control
system, to determine whether a process can access a
particular object (e.g. write to a particular file).
None-the-less, capabilities provide a simple and powerful
security mechanism, because they provide control over
how processes accomplish things, which is something that
most access-control systems can't do/don't do.
- Mandatory Access Control (MAC) Systems
- Mandatory Access Control (MAC) Systems partition a computer
and its operating system into many small discrete pieces.
A user of the system can only use those pieces for which
they have been given access to (i.e. have been granted
the explicit permissions to use.)
MAC systems take the idea of file access control lists (ACL's)
and apply it everywhere: sockets, IPC, scheduling, system
admin tasks, etc. The access relationship occurs between
'subject' and 'object'. A subject is the running
process, the thing that is trying to do the access.
The term object refers to the thing being accessed
(file, socket, etc.). A subject either does, or
does not have the permissions to access a certain object.
fixme.. todo explain how MAC and DTE differ ...
- Domain and Type Enforcement (DTE)
- Domain and Type Enforcement (DTE) is an access-control
technology that limits the access of running programs
to only those objects that they have permission to access.
The permissions policy is fine grained: thus even a program
running as root might not have write (or read) permissions to
files owned by root.
Processes are classed into "Domains". Files, sockets,
and other operating system objects are classed into
"Types". An access policy (prepared by the sysadmin)
defines which access modes a domain can use to access a type.
Access Modes are typically 'read/write/execute' (rwx),
although they can be fancier. (e.g. rdwicl)
The policy also determines the ways in which different domains
can interact, and how transitions between domains can occur
(e.g. during login).
DTE policy is usually specified with a configuration language,
which defines default domains for given binaries, and a type
assignment for objects.
A disadvantage of DTE as a security system is that the rule
sets of which domains can transition into other domains and
access which files can become quite complex and difficult
to audit and verify. As an example, note that many traditional
root exploits in Unix involve 'mistakes' with SUID and file
permission settings. If the far far simpler Unix rwx permission
system can be exploited for mistakes, surely the more complex
DTE policy configurations will have even more holes (albeit
will be far more daunting for the novice cracker to exploit).
- Role-Based Access Control (RBAC)
- Role-Based Access Control (RBAC) defines a set of roles for
users of a system: for example, a 'sysadmin', a 'plain user'
or an 'anonymous ftp' user. Role-based access control is
often built on top of a DTE system, where a user logs into
a certain role, and can thus run programs (domains) appropriate
for that role. In particular, switching between different
domains is determined by the role.
Kind-of like group perms, but different .. fixme todo ..
explain how its different.
- Multi-Level Security (MLS)
- Multi-Level Security (MLS) is ... todo -- fixme.
General Security References
- Wish List of Linux security tools
that need fixing.
- General security news at
- General security news and BugTraq archives at
- Security exploits and system weaknesses are documented at
- Cyberpunks World
is one of those vaguely scary looking web sites (they're hiding
behind the fraudulent EBay web page), whereas
the corporate security site that everyone loves to hate.
- A number of different security tools are listed at
Capability Denial and Access Control Systems
A basic premise behind all security systems is that they
can protect parts of a system even if other parts have been
compromised by crackers.
Access control systems provide a mechanism to make sure that only
authorized users or programs have access only to what they are allowed
to have. Capability systems make sure that a user or program
can perform only those actions that they are allowed to perform.
Most security systems provide a mix of capability and access control,
some emphasizing one over the other to greater or lesser extents.
All of the security systems described on this page are
implemented as one or more kernel modules together with user-space
tools that are used to configure the system. Many (but not all)
of the access control systems attempt to make a clean distinction
between enforcement (the actual mechanics of denying access)
and policy (the decision process used to determine if access
should be granted). Those that do make this distinction often
try to implement a general policy framework, and/or put the policy
framework into its user-space daemon (thus allowing, in principle,
other daemons providing different kinds of policy to be written).
Some of these systems try to leverage existing Linux kernel
security and enforcement mechanisms and frameworks. These include:
- chroot jails, which change the file system root that a process
sees. This limits a process to a subdirectory of the 'real' system.
If the process is cracked, the cracker still cannot get access
to directories outside the jail.
- NetFilter hooks. These are hooks that were added to support
network packet routing, masquerading, filtering and NAT
decisions made by the iptables firewall. These hooks can
be used to enforce security policy decisions by security
modules as well.
- Capabilities. The Linux kernel already provides a framework
that determines whether a given process has the ability to
perform a certain action.
See /usr/include/linux/capability.h for a listing.
Install the libcap-bin deb or libcap RPM
to get the basic capability-manipulating tools.
(Unfortunately these basic tools suck).
sourceforge website is here.)
Linux Security Modules (LSM), a kernel patch that
provides a set of generic security hooks that security kernel
modules can use to do their stuff. LSM was intended to be
sufficiently generic that all security systems could use it,
with a goal of getting it incorporated into the 2.6.x series
- Resource Limits. Resource limits prevent tasks/users
from using up too much of a particular resource, such as disk,
CPU, memory or bandwidth. For example, the shell built-in
ulimit command can be used to set resource limits for
the current shell and its children. The PAM module
/etc/security/limits.conf sets corresponding limits
on any application runn by the indicated user id.
A project to create a more flexible and more powerful resource
manager can be found in the experimental
Here are the systems. I've ranked them in order of 'most favorite
to least favorite', based on a highly subjective evaluation of what
I could read about each project. Note that I'm changing my mind
about 'which is best' even as I write this: caveat emptor.
I've played with a few, but not all of these.
I'm big on systems that are easy to understand,
easy to deploy, focused on doing one thing well rather than
many things poorly, and doing so with a minimum amount of code.
Less code means less bugs, which translates to fewer vulnerabilities.
For example, I keep rediscovering that SELinux seems to be large
and complex, hard to understand, difficult to install and configure.
Which leads me to think that it might be vulnerable. Despite
its impressive roster of credible and capable contributors,
including the weight and heft of the US NSA and American
security/military contracting organizations like
Mitre, its not clear
that SELinux is either the best or most secure system out there.
- The Linux-Vserver
project leverages the existing Linux kernel chroot and capabilities
and adds the abstraction of a 'security context' to create a very
simple yet very powerful security system. A distinct disadvantage
of many security systems, in particular, the MAC-based systems,
is that they are conceptually difficult to understand, making the
tools hard to use correctly, making them prone to sysadmin error.
Complex tools are also hard to audit: they might be hiding flaws
and security holes that allow the 'bad guy' in, but make it hard
for the 'good guy' to find and fix.
The three basic elements of the VServer are:
These elements can be used individually (e.g. named/BIND is often
configured to use chroot), or they can be combined to create completely
independent virtual server environments that are completely invisible
to one another, yet coexist on a single machine. To a user, a virtual
server looks like a complete Linux system, to which they might even
have root privileges. Some ISP's/web hosting services use VServers
to host different customers on the same machine. Note that VServers
add an important file-linkage mechanism to limit the amount of disk
space that needs to be devoted to common files across servers.
(Thus providing a disk-usage advantage over LPAR'ed and VM systems.)
Note that VServer does not provide any MAC/DTE infrastructure beyond
the traditional Unix users/groups. I'm thinking it would be nice
if it did ...
- The security context. A process in one security context cannot
see processes in other security contexts, neither with the
'ps' command, nor with 'cat /proc' nor in any
other way. As side-effect, this means that a process in one
context cannot kill processes in other contexts.
- Capabilities. The existing Linux kernel provides a wide
variety of capabilities which can be taken away from processes.
These include the ability to change network addresses, to
change the ownership of a file, etc. (See
/usr/include/linux/capability.h for details.)
The vserver-utils provides a tool to take away capabilities
from a process.
- The chroot jail. The existing Linux kernel provides
a way to limit a process to a subdirectory, by changing
the 'file system root' for the process to be the subdirectory.
Since a process cannot 'get beyond root', it simply cannot
access anything outside the subdirectory.
Note the V-Server project seems to be in a bit of flux with
regard to the leadership structure/maintainership, etc.
I haven't gotten to the bottom of the politics.
Please do not confuse the VServer with the
Server project, which is something completely different.
(It strives to do the opposite: make many real machines look
like one, whereas VServer tries to make one machine look like
many. We will know that both projects have suceeded when
someone sucessfully layers the one on top of the other and
regains the original.).
- The best documentation is the
- The original
Linux Virtual Server project page.
- The Linux-Vserver
site maintains the current set of kernel patches required
- The Util-VServer
provides the various command-line utilities needed to run vservers.
- Note that the libcap-bin capability-setting utilities suck, they need to
be updated, documented, made easier to use.
- Sample /etc/init.d/bind9 rc file
that uses capabilities and security contexts to minimize the damage
a cracker could do if they broke into the BIND nameserver.
- Rule Set Based Access Control (RSBAC) for Linux
implements the Abrams and LaPadula Generalized Framework for
Access Control (GFAC) in its lowest layers. The framework
enforces access decisions at/near the system call layer.
Access decisions are based on a
quadruplet of (access type, access target, attributes on subject,
attributes on object).
By providing an attribute framework, RSBAC can implement
a variety of MAC policy models, each in its own module.
As of this writing, there are 12 different modules, including
one for MAC, some basics for ACL's, capabilities, chroot and
resource caps, and some more unusual modules as well, such as
a virus (malware) scanner, etc.
This project appears to be alive & well, there's an active
mailing list, an IRC channel. They're also proud of not being
government-sponsored/industry-sponsored. All code is GPL'ed.
- Security-Enhanced Linux (selinux)
The National Security Agency's Security-Enhanced Linux
implements an architecture that separates enforcement from
access policy decisions. The architecture is general
enough that different types of policies can be
Role-Based Access Control (RBAC),
Type Enforcement (TE),
and Multi-Level Security (MLS).
The enforcement module does this by assigning security labels
to each subject or object (persistent and transient). It uses
a security class to determine the kinds of relationship a pair
of labels might have. The triplet consisting of a pair of labels
and a class are then sent to a policy server to determine if
access is allowed. For performance reasons, the security labels
are assigned dynamic integer security ID's (SID's); the reply from
the policy server is cached in an 'access vector cache'.
Work is ongoing, patches are available for the 2.6 kernel.
The kernel module uses LSM.
SELinux includes several toolsets:
the Tresys policy tools (setools),
and the MITRE policy tool (slat). Kernel patches are under
the GPL license; some tools and other patches are under
the BSD license, others are in the public domain.
There appears to be a rather large and active developer
community (i.e. developers external to the original/core
NSA-employed developers), as well as a user community,
mailing list archives, etc., all signs of a project in
- William & Mary DTE
Domain and Type Enforcement for Linux is an implementation
of DTE originally from the College of William and Mary.
As of this writing, (Oct 2003), this appears to be an active
development project, although there does not seem to be much
of a user community (I couldn't find any mailing lists or archives).
Code is GPL'ed. Integrated with the Linux Security Modules code.
Includes a PAM configuration module, and a graphical config utility.
- Medusa DS9
Medusa DS9 provides a mechanism for implementing general
security functionality, including MAC. It is implemented as a
small Linux kernel patch that provides a service interface to a
user-space security daemon. This security daemon implements the
majority of the desired security functionality, including the
policy decisions, keeping these details out of the kernel.
Currently, a policy daemon called "constable" has been implemented
that acts as an authorization server.
The Medusa project seems to be barely alive. It does have working
code on the 2.2 and 2.4 kernels, but there does not seem to be
much active development. There is a public mailing list with
mailing list archives, but its extremely low volume (dozens of
messages a year) which indicates that the project has a low number
of users and is in suspended animation. The project leads are
helpful; they seem to respond to email and have posted their
to-do lists, etc.
- Linux Intrusion Detection/Defense System (LIDS)
- LIDS provides a collection
of intrusion detection and access control functions. The include:
- Support for Access Control Lists (ACL's) on files
- a monitor/alert system for unauthorized (file) accesses
- a port scan detector
- Mandatory Access Control (?) for files and network access.
- running processes can be protected, hidden.
- Tool to manipulate capabilities for running processes
My biggest problem with LIDS is that it seems to be a mish-mash
of different tools with no clear focus, no well-defined function,
and no theoretical grounding. This makes it hard to understand what
the system is really capable for, whether its a complete or a partial
implementation. It makes it hard to understand how much it can be
trusted, and where to look for bugs/security holes.
- The Remus
Linux Kernel Module uses interposition at the system call
interface to implement its access control functionality.
Remus attempts to confine root-privileged and setuid processes
by mediating their use of security-relevant system calls.
Administrators can configure Remus to allow confined
processes to make only certain calls with certain parameters.
Remus appears to be oriented at noticing unusual system
usage (e.g. an off-hours root login), the kind of usage
signatures one might expect of a cracker.
I couldn't find a clear definition of what sort of rules one
might have in the access database. The rules seem to be ad-hoc,
based on the name of a system call and its arguments, rather
than on the object that the system call is trying to access.
As such, not being grounded in a strong DTE/MAC theoretical
framework, it may in fact be a lot better at detecting
inappropriate access than it would be in preventing it.
GPL'ed, appears to be in active development.
- FreeVSD is a chroot'ed
virtual server infrastructure. Allows multiple independent servers
to be set up, each with its own independent IP address, its own
administrator, etc. The theory is that compromise of one server
does not compromise the system.
At this time, the FreeVSD server is down, and there do not appear
to be any mirrors on the net. I can't quite tell if this is
a transient server problem, or if this project is dead.
Google only reveals docs for old, old OS'es (Red Hat 6.2), and
an old release (1.4.7 from April 2001). The mail archive looks thin,
and stops cold on Feb 2003. Based on Google, it seems
this project is dead.
Commercial or Non-Open, Non-Free Access Control Systems
Below are some of the non-Free, non-Open Source access control systems.
- Immunix SubDomain
Immunix SubDomain from WireX
implements a form of MAC similar to DTE; its configuration
retains the notion of domain, but does not make use of types.
SubDomain does leverage standard Linux chroot to help with
isolation between domains. SubDomain makes use of a GPL'ed
kernel patch; the userland configuration tools are proprietary.
Despite a .org domain name, I could not detect any sort of
user community (public mailing list, mailing list archives,
user or developer-oriented website) surrounding this product.
- VXE, the Virtual
eXecution Environment, implements a compartmentalized, virtual
server MAC-like environment. It
enforces the principle of least privilege by confining
processes (such as root-privileged network servers) to virtual
environments in which only the minimum set of resources required
for normal operation are available. VXE virtual environments
are implemented in LKMs and operate with the help of a Linux
kernel patch. Since these virtual environments may be tailored
specifically to the resource needs of a particular application,
VXE provides fine-grained support for restricting applications
to least privilege.
Customizable via LISP(!). Semi-commercial: free for non-commercial use.
- Pitbull LX
Pitbull LX implements a form of Domain and Type Enforcement
(DTE), although it appears to blur the distinctions between domains
and types (subjects and objects), referring to everything as a
'Domain'. Access modes are rwx (read, write execute).
It consists of a Linux Kernel Module (LKM), a PAM module, and
configuration files. The access rules to link together domains
resemble firewall rules.
This appears to be a commercial product; I couldn't tell what
license covers the LKM or if the source was available. There was
no evident user community. Also runs on AIX and Solaris.
The following security/access-control systems appear to be dead/abandoned
at the time of this writing. Whether this means that the technology
was good or bad, I cannot say. The original authors lost interest,
and failed to cultivate a community that could take over the project.
A number of these appear to have been funded by government agencies
or military contracts, and thus work stopped when the funding contract
LOMAC, Low Water Mark Integrity Protection for Linux is
a kernel module that provides a novel and very easy to
administer security scheme. Based on theoretical,
verifiable models of security, compartmentalizes a Linux system
into 'high' and 'low' sides. Processes start out on the
trusted, high side, and fall down when they access any
untrusted object, such as non-system files, or the network.
Processes on the 'low' side do not have write-access privileges
to important parts of the file-system, even if they are root.
Thus, any network daemons are automatically demoted, and
thus system files are protected from worm and cracker breakins
through the network. (i.e. a cracker, even if they manage
to get a root shell by breaking a network daemon, still won't
be able to update certain files in the file system.)
Pro's & Con's:
- Con: Available only for Linux 2.2 kernel, hasn't been ported
- Pro: 'trivial' administration. Almost nothing to configure.
- Con: Doesn't make use of Linux kernel 'capabilities' to remove
other important privileges. A cracker that broke in might
not be able to modify files, but might still be able to change
network settings, change system time, and perform a variety of
more obscure system administration tasks.
This project is currently dead. I (Linas Vepstas) personally
provided and maintained the last few patches and releases for
this system, fixing a number of bugs and adding several
interesting features. The last version is from August 2001,
against linux kernel 2.2.16.
I find the simplicity of the LOMAC policy decisions to be
rather appealing, both from the sysadmin point of view, and
the audit-ability point of view. It may be possible to
resurrect LOMAC by re-implementing it as a policy server
on top of the SELinux enforcement module.
- Kernel Hypervisors
Secure Computing Corporation's Kernel Hypervisors are
Linux Kernel Modules which
"wrap" applications by replacing a subset of the kernel's system
call interface with their own augmented interface. The
augmented interface may filter calls in order to perform access
control, or may augment calls with new functionality, such as
Kernel Hypervisors are a general tool that can be used to
implement a wide variety of security-related functionality.
A Linux prototype is available.
Historically, hypervisors are commercially seen mostly on
IBM mainframes, where the CPU Instructions Set and
Central Electronics Complex CEC implement the hardware
needed to support virtual machines. The 'hypervisor' is
the master controller under the virtual machine.
I can't make out if there is a license for this code; it may be
public domain. There is no user community behind this project;
it is based on research funded by DARPA/U.S. Air Force Research
Labs and appears to have been abandoned in February 1998.
(A few minor updates were made in June 1999).
- Generic Software Wrappers Toolkit
NAI Labs' Generic Software Wrappers project has produced a
toolkit for constructing abstract security enhancements called
Wrappers, which are similar in purpose to SCC's Kernel
Hypervisors, also listed here. The toolkit provides a
life-cycle abstraction for managing the relationships between
Wrappers and processes, and a language for writing Wrappers with
the potential for cross-platform portability. The toolkit
currently supports Linux, FreeBSD, Solaris, and (to some extent)
Windows NT. The toolkit is a general tool for constructing
security enhancements, rather than an implementation of a
particular MAC scheme. GPL'ed.
This project appears to have died; no activity since Oct 2001.
Janus is a tool for confining potentially dangerous processes,
such as privileged servers and web-browser helper applications.
It was originally developed on Solaris using that operating
system's user-space process debugging support. There is now a
Linux port, as well.
The last activity on this project appears to have been in
August 2000. This appears to have been a research project
from a pair of UCalifornia professors, and does not appear
to have an active community.
- Beattie MAC
Beattie MAC implements an integrity-oriented form of MAC in a
kernel patch and a filesystem module. Old. Last release was
an early alpha release for the Linux 2.2 kernel.
- SAIC DTE
SAIC is implementing Domain & Type Enforcement (DTE)
in Linux by modifying the kernel source. Note that the
above URL doesn't resolve into anything anymore, and I was
unable to find a mirror for the old website, nor could I find
a new URL for this project. Ergo, this project must be dead.
Intrusion Detection Tools
Tools that attempt to detect cracking attempts against a system,
and possibly take counter-measures.
- Tripwire. Tripwire detects modified files (files that the system
administrator was expecting not to change, indicating that an
intruder may have installed a Trojan horse, backdoor, etc.)
- Psionic provides nice
log-watching and anti-port-sniffing (intrusion detection) tools.
Port-sniffing is frequently the first phase of an attack against a
site: the cracker is attempting to find out what ports and services
are open on the machine under attack. Detecting when a cracker is
interested in your site is one of the first steps in an active
response to deter future incidents.
- Snort is a GPL'ed
intrusion detection system with a number of traffic monitoring
and detection features. Runs on most Unix's and also
- Remus, see above. Remus can detect inappropriate system call usage,
indicating that an intruder has already broken in, and is making
attempts to gain further permissions and authorities.
Last Updated October 2003 by Linas Vepstas
Copyright (c) 2001 Tim Fraser.
Copyright (c) 2001, 2003 Linas Vepstas.
All trademarks belong to their respective owners.
Portions of this document have been extracted from the LOMAC
documentation. These portions are
Copyright (c) 1999, 2000, 2001 NAI Labs. You may reproduce and
distribute this document so long as this copyright statement and
disclaimer are retained on all copies. Although we have tried to
be complete and correct, this manual is provided with NO WARRANTY.
Go Back to the Enterprise Linux(TM) Page
Go Back to the Linas' Home Page