GnuCash!

Linux Security Systems and Tools

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.

Glossary

Encryption

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

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 authentication systems.

Firewalls

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

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 VM jail.

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 Linux Security.
• General security news and BugTraq archives at SecurityFocus.
• Security exploits and system weaknesses are documented at 2600 and L0pht.
• Cyberpunks World is one of those vaguely scary looking web sites (they're hiding behind the fraudulent EBay web page), whereas AntiOnline is the corporate security site that everyone loves to hate.
• A number of different security tools are listed at Linux Security.

Capability Denial and Access Control Systems

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). (libcap 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 of kernels.
• 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 CKRM project.

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.

VServer

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:

• 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.

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 ...

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 Linux Virtual 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 original documentation
• The original Linux Virtual Server project page.
• The Linux-Vserver site maintains the current set of kernel patches required for V-Servers.
• 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

RSBAC 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 implemented, including 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 good health.

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.

• The original Willaim and Mary DTE web page.

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.

Remus

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

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

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

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.

Dead/Abandoned Projects

LOMAC

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 to 2.4/2.6
• 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 auditing. 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.

• Original FTP Site

Janus

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

• 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 Win32/95/98/00.

• 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.

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