College of Engineering & CS
Wright State University
Dayton, Ohio 45435-0001

Securing a Linux Kernel

 

Prabhaker Mateti

 
We describe the issues involved in securing a  Linux kernel.  A companion article considers the security of entire distributions based on the Linux kernel. We describe areas of tightening security prior to the compilation of OS kernels rather than after their deployment.
.
 

Abstract: We describe the issues involved in securing a  Linux kernel.  A companion article considers the so-called "secured distributions of Linux". We describe areas of tightening security prior to the compilation of OS kernels rather than after their deployment.  We do not consider applications, not even such standard services as syslogd, kerneld and inetd. We do consider the loading and unloading of "modules" (cf. insmod  and rmmod), and a few network configuring tools as part of the kernel. We focus on the Linux kernel 2.4.x series.

We survey all known re-designs of the kernel.  We contribute several of our own suggestions. We conclude with an outline of how a secure kernel can be put together incorporating all compatible security enhancements from the standard components as distributed by the Linux kernel group.

Table of Contents

  1. Educational Objectives
  2. Terminology
    1. Secure Operating Systems
    2. Trusted Operating Systems
    3. A Practical Definition of What a Linux Kernel is
  3. Secure Kernel Ideas
    1. Capabilities
    2. Authorizations and Privileges
    3. Access Control Lists
    4. Stack Protection
    5. Loadable Modules
    6. Source Code Audit
  4. A Study of Linux 2.4 Kernels
    1. Some Examples of Kernel Bugs
    2. Loadable Modules
  5. Making Linux Kernel Secure
    1. Careful Recompilation
    2. Kernel Audit
    3. NSA Security Enhanced
    4. RBAC
    5. Linux Security Modules
  6. Acknowledgements
  7. References

Educational Objectives

This article is a comprehensive introduction to what is involved in securing a  Linux kernel.  A companion article considers the so-called "secured distributions of Linux".  By a distribution, we mean a collection of system tools, applications and, of course, the kernel.  Securing a distribution therefore includes securing the kernel itself.  Securing a kernel is not only a harder topic, but also a topic of specific interest to us and we separate the discussion of kernel per se into this article.

In this article, we describe areas of tightening security prior to the compilation of OS kernels rather than after their deployment.  We do not consider applications, not even such standard services as syslogd, kerneld and inetd. We do consider the loading and unloading of "modules" (cf. insmod  and rmmod), and a few network configuring tools as part of the kernel. We focus on the Linux kernel 2.4.x series.


Terminology

We distinguish, even though it is not common yet,  "proper configuration" from  "hardening a system" from "fortification" from "designing an OS from scratch with security as a significant requirement". There are also "secure operating systems" and "trusted operating systems."  Alas, no one can offer technically rigorous definitions for these terms. For example, there is regular Solaris and there is Trusted Solaris.  It is also telling to find the following quote, "Windows NT is a secure operating system but only if it's configured correctly."  Both NT,  and several of Unix derivatives claim to be secure and trusted.

Proper Configuration

Systems as distributed are often loosely configured.  Occasionally this is due to sloppiness of the distributor.  More commonly it is because the distributor has tried to configure a generic appeal-to-all setup.  So, it is important that we examine the configuration at length and determine what if any changes must be made.

Proper configuration of the system as given is a prerequisite to either fortifying or hardening.  Systems as distributed are often loosely configured.  Occasionally this is due to sloppiness of the distributor.  More commonly it is because the distributor has tried to configure a generic appeal-to-all setup.  So, it is important that we examine the configuration at length and determine what if any changes must be made.

Fortification

Fortification is about adding a layer of protection beyond proper configuration of the OS and applications. This layer of protection consists of tools that help detect changes in the system and monitor (suspicious) system activity.  Fortification is the addition (and in some cases deletion) of packages to improve security.  It should be done after a system has been properly configured with the supplied components.  Fortification frequently will discard a supplied component in preference to a carefully chosen added component. 

Trustix is an example of a fortified Linux.  It is based on the Red Hat distribution, but removes certain packages, and also replaces certain packages with "more secure" ones.  The Bastille script also falls into this fortification category.

Hardening

The article titled "Hardening an Operating System" is about hardening in general, and should be read prior to reading the present article which focuses on hardening the Linux OS. In this article, we will be mostly concerned with hardening the Linux kernel, version 2.4 (July 2001 approx.)

Kernel v. OS v. Distribution

The word "kernel" is used variously in the OS literature.  In the academia, it generally refers to a nucleus.  In the computer industry, it refers to all the software that runs with the CPU in the kernel mode.  In the IT industry, it refers to everything that comes in a shrink-wrapped box excluding such programs as shells, terminal emulators, GUI etc.

A Practical Definition of What a Linux Kernel is

In this article, we need a working a definition.  Rather than enter into a long debate trying to settle this definition, we consider the following to be "the Linux kernel."  By kernel source we mean all the source code that compiles and links into

  1. the file bzImage, that is typically installed as /boot/vmlinuz
  2. the files collectively known as modules that are typically installed into the directory /lib/modules.
  3. the following system utilities: insmod, rmmod, ...

Secure Kernel Ideas

Notes: most kernels permit hiding processes and loaded modules

Fine-grained privilege

On any computer system, certain operations must bypass the security constraints normally imposed by the system. For example, in order to create a backup, the backup operator must be able to run a backup program that is able to read all files on the disks, even though the operator would not normally be allowed such access. Other programs must also be carefully controlled, such as the programs to shut down the system, create new users, and repair damaged file systems. On a standard Unix system, there is one user ID, called the root, that can bypass all security restrictions and limitations.  On Windows NT/2000 systems such privileged accounts are  "System" and "Administrator".

The inability of standard Unix to grant rights on a finer granularity is a weakness. Also, when one process invokes another, the newly created process runs with the user ID of the first.  As a result, the technique of exploiting a bug in a root program to start an interactive shell has been known for two decades.

We would like such privileges broken down into finer grained privileges. Thus, we would like to grant the backup program the privilege to read any file, but it must not have the privileges to shut down the system, to modify files, or to, say, send random network packets. The use of many limited capabilities instead of a single all-powerful mechanism is called the least privilege principle.

Capabilities

A capability, as used in the general OS literature, is a "token", much like the identification badge that a typical employee of a company wears, used by a process to prove that it is allowed to do an operation on an object. The capability is a coding of both the object and the operations allowed on that object. Intuitively, it as both an identification badge for the process, as well as a complete list what it can do. E.g., a file descriptor obtained when opening a file is a capability.  Occasionally, we call such things "handles." 

Operations on capabilities include copying, transferring to other processes, modifying, and revoking a capability. A capability often has a notion of an "owner" who is able to invalidate all copies and derived versions of a capability.

POSIX "capabilities" (described in the now defunct POSIX draft 1003.1e) are quite different. These capabilities are a partitioning of the all powerful root privilege into a set of distinct privileges.  A process has three sets of bitmaps called the inheritable (I), permitted (P), and effective (E) capabilities. When a process attempts a privileged operation, system will check the appropriate bit in the effective set of the process, instead of checking whether the effective user id of the process is 0 as is normally done. For example, when a process tries to set the clock, a POSIX-capability kernel will check that the process has the CAP_SYS_TIME bit (currently bit 25) set in its effective set.

"The permitted set of the process indicates the capabilities the process can use. A process can have capabilities set in the permitted set that are not in the effective set indicating a temporarily disabled capability. A process is allowed to set a bit in its effective set only if it is available in the permitted set. The distinction between effective and permitted capabilities exists so that processes can bracket operations that need privilege.

"The inheritable capabilities are the capabilities of the current process that should be inherited by a program executed by the current process. The permitted set of a process is masked against the inheritable set during exec(). Nothing special happens during fork() or clone(). Child processes and threads are given an exact copy of the capabilities of the parent process.

Mandatory Access Control

The traditional Unix limits access to files through the notions of owner, group and the rest of the users. This model is unacceptable for higher levels of security.  Additional security attributes called sensitivity labels (SLs) are added to system resources such as files, processes, network ports, interfaces, and host addresses.  Access control using system-enforced labels is called mandatory access control (MAC).   

For example, incoming packets from a network interface can be assigned SLs, perhaps based on the source IP address or the network interface. Outgoing packets will have the label of the process or daemon that created them. An incoming or outgoing packet will be dropped if the SL of the packet is not valid for both the interface and the remote host.  Network services, such as HTTP daemons and associated CGI scripts, can be given read-only access to web pages and CGI directories and can be completely isolated from other resources (such as internal network interfaces, system files, and other network daemons). A network server configured in this way can protect its web pages and CGI scripts from ever being modified from an external connection, even if damaging bugs exist in the software that allow incoming users to execute any random sequence of machine instructions. 

Authorizations and Privileges

Authorization is an attribute of a user account that enables the user to execute a subset of  the available programs. Privileges are attributes assigned to programs that give them different grades of access to system resources. Together, these two sets of attributes enable programs to behave differently toward different users. Applications can be extended to define and check new authorizations, providing a standardized protocol by which applications and the operating platform can communicate to grant permissions to users. Authorizations can be used to divide administrative duties into separate roles, which can then be assigned to different users.

Independent Validation

Secure kernels should undergo evaluation of their overall design, verification of the integrity and reliability of their source code, and systematic, independent penetration evaluation. ITSEC (Information Technology Security Evaluation Criteria) is an internationally recognized set of standards for the evaluation, testing, and certification of IT security products. ITSEC certification, performed by an independent body,  tests the claims made about the security functionality of a product against a predetermined level of assurance.

Access Control Lists

Access Control Lists (ACLs) support fine-grained permissions. Arbitrary users and groups can be granted or denied access in addition to the three traditional classes of users. POSIX 1003.1e Draft Standard 17 Access Control Lists are now part of many commercial UNIX systems. Extended Attributes are arbitrary name/value pairs that are associated with files or directories. They can be used to store system objects (e.g., capabilities of executables, or Access Control Lists) and user objects (e.g., the character set or mime type of a file). Access Control Lists are implementable as extended system attributes.

"When a system has been "exploited" (rooted), it's commonly believed that complete control over the system has been achieved. This is rarely, if ever, true (unless the running kernel has been modified, but that is not the original problem). What has actually happened is the cracker has elevated his or her permissions to the point where the discretionary access protections do not prohibit anything. But the access control checks are actually still taking place. It is a "feature" of the access control system to allow this misuse. Access Control Lists (ACLs) make access control much more flexible for the user to share data with particular users, but do nothing for the security problems of the system administrator."

ext2-fs ACL project

""Currently, there are at least three different access control projects that utilize the foundation set forth by the 2.4 kernel, many cryptography projects to provide IPSec compliance and interoperability with commercial products, and much more.

Role Based Access Control

Processes are assigned "roles" and levels of access that can be extremely fine-grained. For example, Apache can be assigned a web-server-role and be restricted to certain activities.  A port, for example port 21, can be defined as an object and then grant access to this port only to the FTP system. Even a program running with root privileges (such as bind) would not then be able to use port 21 as it would on an ordinary system.

RBAC implies large scale kernel patches, patches to system tools, etc.

Security Policies and their Enforcement

Loadable Kernel Modules

Sand Boxes

chroot jail

Subdomains

A sub domain  specifies on a per program basis which files it can access and how. So, e.g., a cgi script, even if hijacked by an attacker would not be able to write to /tmp.

Subjects, Objects, and Access Matrices

Domain and Type Enforcement

Domain and Type Enforcement is a mandatory access control system which assigns types to files and domains to processes. Access from domains to other domains and from domains to types is enforced according to the DTE policy.

Type enforcement  is a partially ordered non-hierarchical labeling system combined with access mapping from a similarly labeled execution domain. For labeling subjects, all processes are confined to "domains". Objects (e.g. disk files) have labels known as "types". And each domain has specific permissions to do things to any particular type, say to read files in that type. Programs can't change domains unless the system lets them. Domain configurations are either strictly controlled or can't even be modified in multiuser mode, depending on the implementation.

Stack Protection

System Call Monitoring

Defeating TCP/IP Stack Fingerprinting

http://www.usenix.org/publications/library/proceedings/sec2000/smart.html 

Matthew Smart, G. Robert Malan, and Farnam Jahanian, University of Michigan

"This paper describes the design and implementation of a TCP/IP stack fingerprint scrubber. The fingerprint scrubber is a new tool to restrict a remote user's ability to determine the operating system of another host on the network. Allowing entire subnetworks to be remotely scanned and characterized opens up security vulnerabilities. Specifically, operating system exploits can be efficiently run against a pre-scanned network because exploits will usually only work against a specific operating system or software running on that platform. The fingerprint scrubber works at both the network and transport layers to convert ambiguous traffic from a heterogeneous group of hosts into sanitized packets that do not reveal clues about the hosts' operating systems. This paper evaluates the performance of a fingerprint scrubber implemented in the FreeBSD kernel and looks at the limitations of this approach."

Source Code Audit

Formal Program Verification


A Study of Linux 2.4 Kernels

This section summarizes the architecture and features of Linux kernel series 2.4 that are relevant to security issues rather than increased usability or performance.

Some Examples of Kernel Bugs

Two security bugs found in recent (October 18, 2001) Linux kernels (2.4.x, x < 12).

Race Conditions

"Temporary file race vulnerabilities occur when privi-leged programs attempt to create temporary files in an unsafe manner. ŇUnsafeÓ means Ňnon-atomic with respect to an attackerŐs activities.Ó There is no portable standard for safely (atomically) creating temporary files, and many operating systems have no safe temporary file creation at all. As a result, many programs continue to use unsafe means to create temporary files, resulting in widespread vulnerabilities. This paper presents Race-Guard: a kernel enhancement that detects attempts to exploit temporary file race vulnerabilities, and does so with sufficient speed and precision that the attack can be halted before it takes effect. RaceGuard has been imple-mented, tested, and measured. We show that RaceGuard is effective at stopping temporary file race attacks, pre-serves compatibility (no legitimate software is broken), and preserves performance (overhead is minimal)."

Domain and Type Enforcement for Linux

""Access control in Linux is currently very limited. This paper details the implementation of Domain and Type Enforcement (DTE) in Linux, which gives the system administrator a significant advantage in securing his systems. We control access from domains to types, domain transitions, and signal access between domains, based on a policy which is read at boot time.

""Access control in Linux currently consists of traditional Unix permissions and POSIX capabilities[Caps-faq]. Domain and Type Enforcement (DTE) has been presented [DTE95,DTE96] as a useful method for enhancing access control. DTE groups processes into domains, and files into types, and restricts access from domains to types as well as from domains to other domains. Type access can be any of read, write, execute, create, and directory descend. Domain access refers the right to send signals as well as that to transition to a new domain. A process belongs to exactly one domain at any particular time. A process transitions to a new domain by executing a file which has been defined as an entry point to that domain. The three types of domain transitions are auto, exec, or none. If Domain A has auto access to domain B, and a process in domain A executes an entry point for domain B, then the process will be automatically switched to domain B. If domain A has exec access to domain B, then a process running under domain A can choose whether to switch to domain B on execution of one of B's entry points. DTE can be considered an abbreviated form of classical capabilities[Dennis66]. In a system based upon classical capabilities, a process carries with itself a set of access rights to particular objects. At any point, a process can give up, or reclaim (if permitted) some of its capabilities. POSIX capabilities work similarly, but these capabilities are limited to a predefined subset of super user access rights such as the ability to nice a process, boot the system or open a privileged port. In DTE, a process carries with itself only an indicator of the domain in which it runs, and this determines the process' access rights. A process can enter a new domain (and hence change its access rights) only upon file execution. Trusted Information Systems has used DTE in its proprietary firewalls, but details of its implementation were not publicly available, and TIS appears to have stopped using DTE altogether. A group at SAIC has recently begun a DTE for Linux implementation [SAIC-DTE]. Jonathon Tidswell and John Potter[Tidswell97] submitted theoretical work on extending DTE to allow safe dynamic policy changes, but have attempted no implementation. Presented here is our prototype implementation of DTE for Linux version 2.3.

Loadable Kernel Modules

""Loadable kernel modules provide an interface to hardware devices and data within the kernel memory. Most Unix systems enforce the usage of loadable kernel modules in order to offer maximum interaction with the peripherals and the kernel.  Due to those features, kernel modules have gained the interest of intruders, since they affect the operating system at the basic level and guarantee an efficient and hard to detect way to manipulate the system. In the past years loadable kernel modules including backdoors have been published for Unix systems such as Linux and FreeBSD.

http://www.linuxsecurity.com/resource_files/host_security/lkm.htm 

Making Linux Kernel Secure

This section summarizes various contributions that make the Linux kernel more secure.  Note that these are separate contributions.  To our knowledge, there has been no attempt yet to synthesize all these into one kernel that keeps pace with new releases of the standard kernel.

Careful Recompilation

Stack smashing (buffer overflow) attacks are among the most common.   By and large, these are programming errors that can be caught by analytical techniques.  Newer compilers are mechanizing these techniques.  For example, such vulnerabilities are carefully checked by the Immunix's "StackGuard" enhancements to the GNU egcs compiler.  An entire RedHat distribution has been recompiled with this compiler resulting in the distribution of Immunix.

Libsafe 2

LD_PRELOAD environment all of your users won't be able to execute anything anymore. To fix this you have to deactivate CONFIG_GRKERNSEC_GLIBC_EXECVE.

Patching a Kernel

Patches are often released in binary form, but they they can also be at the source code level.  These replace section(s) of code in the kernel.  Often a patch is in response to a newly discovered security hole.  But, there are proactive modifications also in the open source OS. For example, consider the following entry taken from www.packetstorm.com

File Name File Size Last Modified
grsecurity-1.6-2.4.7.patch 250852 Aug 5 01:27:50 2001
Grsecurity is a set of security patches based on code from hap-linux and openwall which have been ported to the 2.4.7 kernel. It features a non-executable stack, /proc restrictions, chroot restrictions, linking and fifo restrictions, exec and set*id logging, secure file descriptors, stealth networking enhancements, signal logging, failed fork logging, time change logging, and more. Changes: Random IP id code has been completely rewritten, a bug in the linking restrictions has been fixed, and a new ACL system has been introduced.  Homepage: http://www.getrewted.net.

LIDS (Linux Intrsion Detection System)  is a series of proactive kernel patches  [www.lids.org , and www.soaring-bird.com.cn/oss_proj/lids/].  It provides protection from root exploits by disabling some functions that can be used to gain unauthorized access to root. Features such as disabling the loading of modules, locking routing tables, protecting daemons from signals, read-only and append-only flags to protect programs or log files from a root intruder, implementation of 'capabilities', and much more.

Kernel Audit

http://www.lkap.org/mission.html 

not to be confused with a security audit of a system.

Flask: Flux Advanced Security Kernel

 http://www.cs.utah.edu/flux/fluke/html/flask.html Flask is an operating system security architecture that provides flexible support for security policies. The architecture was prototyped in the Fluke research operating system. It is now being applied to the Linux operating system (Secure Linux).

NSA Security Enhanced

http://www.vnunet.com/News/1125743 The National Security Agency (NSA) has released its second public version of the Security Enhanced Linux operating system. Although still in prototype, the Linux Security Modules based OS is designed to be an almost uncrackable development of the open source platform, which can be confidently used for "certain sensitive or classified applications and environments".

The agency has been working on the Security Enhanced implementation since February this year, and released the first public prototype in May. Features of the second release include a number of bug fixes, as well as a kernel update to the more recent 2.4.10 Linux kernel.

"This version of Linux has a strong, flexible mandatory access control architecture incorporated into the major subsystems of the kernel. The system provides a mechanism to enforce the separation of information based on confidentiality and integrity requirements. This allows threats of tampering and bypassing of application security mechanisms to be addressed, and enables the confinement of damage that can be caused by malicious or flawed applications."

The project was started when the NSA decided that existing mainstream operating systems lacked the critical security feature required for enforcing separation - mandatory access control.

"As a consequence, application security mechanisms are vulnerable to tampering and bypass, and malicious or flawed applications can easily cause failures in system security," the organisation said.

By Liesbeth Evers, Network News [13-06-2001] The US National Security Agency (NSA) has released a prototype version of security-enhanced Linux, claiming it offers far stronger protection than most of the operating systems (OSs) currently on the market.

The agency believes that popular OSs, such as Windows and Solaris, are incapable of supporting advanced security mechanisms because security is not in-built as part of the kernel.

Most OSs are based on discretionary security, where measures are added later, it said. This makes it easier for intruders to circumvent measures such as digital signatures, encryption and firewalls.

In an NSA report obtained by Network News, the agency warned: "Any security effort which ignores this fact can only result in a fortress built upon sand."

David Lindeijer, a software designer at Delft University in Holland, backed the NSA's stance, saying that discretionary security left networks open for abuse. The university has moved from Solaris to Windows, but found neither OS could support firewalls well enough to prevent crackers breaking in.

At the University's Transport Labs, where Lindeijer runs a project on internet-steered transport charts, he secured the lab's network by running it on an OS based on Java where security is part of the kernel.

"It is stupid that mainstream OSs leave security as discretionary. Mandatory security causes some operational problems, but they're small compared to the damage caused by security breaks," he said.

Tim Graves, security expert and Solaris architect at Sun Microsystems, said the company had developed Trusted Solaris with mandatory B1 security. Sun is now considering whether to move some of its B1 security into standard Solaris.

Although more expensive to maintain, this would provide significantly better protection.

"Banks, governments, internet service providers and web hosting companies should run networks on secure OSs. Others should use a combination of a mainstream OS and a B1 OS. In that way they have security at relatively low cost," said Graves.


VXE - Virtual eXecuting Environment

One of the main problem with UNIX security is that super user can do with system anything he wants. There are programs (daemons) which work with super user privileges, for example popd, sendmail, and accessible from network (Internet/Intranet). There are bugs in many of these programs. An  intruder connects to such programs via network, exploits existing bugs in it and gets control over all of the host. 

"VXE creates virtual environment for each subsystem. In such environment only needed for normal work resources are visible and available for subsystem. Subsystem here, is startup program and all sub processes initiated (forked) by it. Any sub process runs in the same VXE that the parent. To affect any system resources, program use OS system calls (syscalls). VXE has means to describe what system calls, with what parameters are available for each subsystem. For example, it can be described (for file operation syscalls) that some files are readable and some executable, network operations unavailable (in case of POP server - it handle network connection, but doesn't make new ones) and this restrictions can't be broken even by a program with super user privileges.

These restrictions can be as smart as needed. If intruder gets a control over such subsystems, he can't use ordinary methods to sniff information or affect the system. Everything he can do in theory, using sophisticated methods, - is to affect the work of hacked subsystem, but not OS itself, nor another subsystems. Here, ordinary methods, are those, when intruder gets super user privileges and runs command interpreter (shell), and ordinary utilities, such as text editor, copy utility and so on. He can't do anything without such utilities. For example, POP server doesn't need text editor and copy utility for it's work, so there is no such programs in VXE environment, created for POPD protection.

More exactly, VXE protects system and it's subsystems from interference of hacked subsystem (which works under the control of VXE). And as side effect, provides protection of subsystem itself (in a way described above). For simplicity, in the following text, we will say that VXE protects subsystem.

VXE description (VXED) is small LISP program (set of functions) which use declarative description of acceptable parameters for different system calls. This VXED loaded to the kernel, controls system calls parameters from the specified subsystem. So VXEDs are dynamically loadable modules, handled by the small LISP interpreter, inserted into the kernel. In current VXE version, this is vxelisp, derived from RefLisp  (Bill Birch birchb@ozemail.com.au). vxelisp has new internal bigstring representation, full set of string and bit functions. Kernel version of vxelisp is reentrant, to handle different VXEDs simultaneously.

There are two methods to activate VXED. Explicit and implicit (automatic). Explicit activation is done by vxe program. Parameters are VXED pathname, path and parameters of executable, which will be run with restrictions, described in named VXED. For automatic method, vxed utility preloads all needed VXEDs into the kernel. Each VXED has activation pattern. During program start (exec), kernel checks executable path against patterns. VXED with matching pattern is activated. This method can be used, to activate protection at the start of any program in specified directory (and all subdirectories). For example, to protect system from CGI scripts, supplied by users, VXEDs can be defined for each user subdirectory.

Any sophisticated VXED can be created manually, using full power of vxelisp. But VXE doesn't force administrator to learn and use LISP. One can think about VXE as of self-learning system. VXE development system (DS) runs VXE in trace mode.

Such run makes description of permitted (used) system calls. Creation and modification of VXED is made via WWW interface. Development system supports two types of VXED. Strict and filesystem types. Strict VXED describes all permitted syscalls explicitly. Filesystem VXED describes read, write, and execute permissions for defined paths. Specified restrictions apply to filesystem syscalls, all other syscalls are permitted. After VXED has been created for particular subsystem, VXED works in soft mode. In this mode all violations of VXED are logged, but syscalls are performed. VXE DS can upgrade VXED automatically, using logged information.

Surely, needed changes in VXED can be done manually using VXED editor. Violations can be caused by intruder activity or by deviation in subsystem's behavior under various circumstances. VXE administrator reviews log with the help of DS and makes decision, if upgrade is reasonable. If there are no violations, VXED can be switched to production mode. In this mode violations are logged and syscalls are blocked (fail). Once again, the log can be used for intruder detection or for VXED upgrade (tuning).

For security reasons, all control actions over VXE can be done only by super user and outside any VXE.

VXE affects performance in following ways. If program runs outside any VXE, every syscall executes two assembler instructions more (checks if VXE is in effect for current process and jump if no). For every exec syscall a small C subroutine checks if there is a matching VXED already available in the kernel. For programs that run in VXE, a few lines of C code checks if parameter verification is needed. Some syscalls can be marked in VXED as uncheckable (for example, by default, read and write operations). And only the rest syscalls are checked by very small LISP functions. These functions located in VXED and can be easily observed by administrator.

Two types of VXED are two security policy models. New models can be implemented without any changes in the kernel. "

Hypervisors

A hypervisor is a loadable kernel module providing a sand boxed wrapper.  A master kernel hypervisor coordinates installation and removal of individual client kernel hypervisors and manages the clients. This framework allows client kernel hypervisors to be stacked so that a variety of application specific policies can be implemented, each by means of its own kernel hypervisor. The hypervisors run in the kernel, but since they are loadable modules, they do not require that the kernel be modified.

LSM, Linux Security Modules

Notes: include/linux/security.h

Another Linux ACL project that is now defunct

ACL for ext2 from the LiVE! project of the University of Bremen, Germany.

grsecurity

grsecurity is a set of security patches for Linux 2.4 that contain all the features of Openwall and HAP-Linux, among many other patches for 2.2, and other OS's. It features the Openwall non-executable stack, PaX, the Oblivion ACL system, /proc restrictions, chroot restrictions, linking and FIFO restrictions, exec and set*id logging, secure file descriptors, trusted path execution, randomized IP IDs, randomized PIDs, randomized TCP source ports, altered ping ids, randomized TTL, better IP stack randomness, socket restrictions, sysctl support on nearly all options, secure keymap loading, stealth networking enhancements, signal logging, failed fork logging, time change logging, and others.

Linux Trustees

Linux "trustees" is a permission management system. It is inspired by Novell Netware approach and Java security API. Special objects, called trustees, bound to every file and directory,  describe the permissions granted (or denied) to certain user or group (or all except user or group), with the default being deny. The trustees objects are stored in the kernel memory that allows for fast lookup.  The permission to access a file (or directory) is calculated as follows:

Note, that string names (not i-node numbers) are stored in trustees object, so the trustee system is work despite of the mount points, file system types etc.

Reference Monitor for Unix Systems

REMUS (REference Monitor for Unix Systems) provides a reference monitor implemented both as a loadable kernel module and as a kernel patch.  It can detect illegal invocations of system calls, and also prevent loading of malicious kernel module.  It also integrates the Access Control Database (ACD) with the Unix standard virtual file system /proc. The system administrator sees the ACD as a directory, each file contains the set of rules for a given critical system call.  REMUS employs a simple mechanism for system calls interception at the OS kernel level and requires minimal additions to the kernel code and no change to the syntax and semantics of existing system calls. The execution of system call is allowed only when the invoking process and the value of the arguments comply with the rules kept in an Access Control Database (ACD) within the kernel. Common penetration techniques that involve tricking the system into running the intruder's own program in privileged mode are blocked by this approach. In particular, REMUS blocks buffer overflow attacks before they can complete.

Hypersec Kernel

Hypersec is a collection of security patches applied to the standard kernel:

  1. [OpenWall-1 Patch]
  2. [HAP-3 Linux Patch]
  3. [RSBAC-1.1.1 Patch]
  4. [PP DiskDriver-1.2]
  5. [Sec00r-2.2.19 Patch]
  6. IPVS-1.0.6 Modules
  7. [FP Patch]
  8. [KernelI-2.2.19]
  9. [PAX-2.2.19]
  10. Raw I/O Patch

It integrates cryptography and support for encrypting loop back devices, random PIDs and random TCP Sequence Numbers, Mandatory Access Control, Access Control Lists, non-executable heap and stack areas, restricted /proc and /tmp, protection against TCP OS fingerprinting.

Capabilities

As you know, the "root" user normally has complete control over all functions of a Linux box. Binding to a privileged port, loading kernel modules, and managing filesystems are examples of things that typically can only be done by root. If a regular user needed to run the "ping" command, for example, it was necessary to make it run with the privileges of the root user. The ping binary needs root privileges in order to open a raw socket (an operation managed by the kernel) to create the necessary ICMP packet for the echo request.

Another classic example is the time server, xntpd. In order to bind to the privileged ntp port, the daemon requires root privileges. If we could somehow simply supply the ntp daemon with root privileges for the time it takes to manipulate the system clock as the daemon starts, then lower its privileges to that of a normal user before processing actually starts, we can significantly reduce the potential for a programming error from compromising the whole system.

Once these privileges are relinquished, it's effectively gone until the next reboot. Even another root process cannot regain those privileges.

This is where capabilities become a critical next step in the evolution of system and kernel security. Capabilities support extends the UNIX security model and allows Linux to provide more fine-grained access to privileged system commands. It is a set of "rules" that can be assigned to processes, users, and files that even the root user must follow.

Linux 2.2 introduced basic support, but a modification by Chris Evans to the 2.4 kernel turned capabilities into a system that is largely useable and can be programmed into many of the common services, such as the ntp daemon. Chris' change involved a modification to the prctl() system call that permits a program implementing capabilities to retain its existing level of capabilities while switching from running as root to a non-root user.

Originally a POSIX.1e specification, now withdrawn but still a useful guide, Linux 2.4 implements nine of the capabilities from the original draft, and an additional twenty-one that are specific to Linux.

Some of these capabilities include the ability to change file ownership, kill processes, control kernel module management, reboot or shutdown the machine, manipulate the system clock, and more. One can immediately see how powerful this is -- processes that are normally set-user-id root such as /bin/ping or simply must be run as root can now run with just the privileges they need and no more, diminishing the likelihood of a security problem resulting in a system compromise.

Capabilities can also be controlled on a system-wide level using a "bounding set." The ability to load or unload modules might be one such capability. The CAP_SYS_MODULE might be disabled once the system has booted and entered the normal multi-user level to prohibit the loading or unloading of kernel modules essentially until the next reboot. Using the lcap command, one might disable the ability to load kernel modules using the following:

  [root@magneto /root]# lcap CAP_SYS_MODULE
This would typically be done at the first point at which all the necessary modules have been loaded. This is an effective countermeasure against a malicious intruder attempting to install a backdoor kernel module. The CAP_SYS_RAW_IO capability would also disabled to prevent hacking kernel memory directly using /dev/kmem.

A program such as xntpd might go through the following process to relinquish the rights that are not necessary for normal operation:

Future changes yet to be completely implemented include the modification to commands similar to chattr(1) to modify and tag files that will one day totally remove the concept of a "root" user. The goal is to provide the ability for a command-line tool to add or remove privileges in much the same way we current add or remove permissions using chmod(1).

Currently, programs need to be modified to take advantage of capabilities. With filesystem capabilities, this sometimes won't be necessary. It might go something like this:

  [root@magneto /root]# chattr +CAP_BIND xntpd
This would enable the xntpd process to bind to a socket without requiring root privileges prior to being run. Quite powerful. At the same time, it's also contains a certain potential danger due to making an unprivileged binary slightly privileged.

 

Open Source Cryptography

Encryption is the key to the next generation of Internet communications. No longer is it possible to use the protocols that were commonplace in times before electronic commerce, companies relying on their Internet presence for interacting with customers, and even basing their corporate image on it.

Changes in the crypto export regulations in October of 2000 now make it possible to not only distribute open source cryptography from a web site freely, but also object code derived from open source software. The origin location of the source code must send a message to the Bureau of Export Administration indicating their intent.

The kernel.org web site now has a cryptography repository, and contains crypto extensions to the new 2.4 kernel that provide the ability to encrypt filesystems, create virtual private networks, and more.

I had an opportunity to speak with Alexander Kjeldaas, the lead developer for the kernel crypto work, and asked him about the state of support of crypto in the 2.4 kernel.

 

"Lots of ciphers are supported -- the ones most currently used such as Blowfish, IDEA, Serpent, AES, 3DES, DES and others. Some digest algorithms are also supported - MD5 and SHA1. No hardware acceleration is supported yet. The API is mostly synchronous the way most crypto APIs are designed, but when we start getting hardware acceleration this might change and we might get an asynchronous interface -- developing this interface will probably be done with an eye on the IPSec needs. Only symmetric ciphers are supported -- no asymmetric stuff (RSA, etc.) is supported or planned."

 

Quite a number of improvements have been made since the crypto that was developed for the 2.2 kernel. Alexander writes, "Previously cipher modules could be looked up by number or by name. This was to be compatible with the old /dev/loop interface that requested "transforms" by number. In 2.4, the numbering scheme is removed which means that users no longer have to include a lot of entries into /etc/modules.conf to use encrypted block devices. It also means that other developers that wants to create their own module for various projects don't have to allocate global "IDs" for their modules." Alexander continues by stating that he is confident that crypto will be integrated into the kernel, but feels there are some further code changes that need to be made before this can be done. Once these final code changes are complete, the group will push further for inclusion in the mainline kernel tree.

He also gave me some insight into what changes we can look forward to with regard to security and Linux in the future.

Other crypto-related stuff to look forward to:

Kernel Devices and Configuration Options:

The 2.4 kernel includes a few block and character devices available on Linux that will also help you with security. Although not necessarily new in the new 2.4 kernel, they are relatively unknown but extremely powerful.

These devices, /dev/random and /dev/urandom, are managed by the kernel and provide random data at any time for any number of applications. This might include generating random passwords, seeding TCP sequence numbers, and even cryptographic functions.

Both /dev/random and /dev/urandom should be secure enough to use in generating PGP keys, SSH challenges, and other applications where secure random numbers are requisite. Attackers should be unable to predict the next number given any initial sequence of numbers from these sources. There has been a lot of effort put in to ensuring that the numbers you get from these sources are random in every sense of the word random.

The only difference is that /dev/random runs out of random bytes and it makes you wait for more to be accumulated. Note that on some systems, it can block for a long time waiting for new user-generated entry to be entered into the system. So you have to use care before using /dev/random.

/dev/random is high quality entropy, generated from measuring the system interrupt times and other events which are non-deterministic. It blocks until enough bits of random data are available.

/dev/urandom is similar, but when the store of entropy is running low, it'll return a cryptographically strong hash of what there is. This isn't as secure, but it's enough for most applications.

You might read from the devices using something like:

  [dave@magneto ~dave]# head -c 6 /dev/urandom | mmencode
This will print (approximately) six random characters on the console, suitable for password generation. You can find mmencode(1) (perhaps also known as mimencode on some systems) in the metamail mail package.

See /usr/src/linux/drivers/char/random.c for a description of the algorithm.

 


Acknowledgements

The above serves as a quick introduction to the many Linux distributions that claim to be secure.  We intend to turn this document into a properly written technical report in the next few weeks.

Notes: include/linux/security.h


References

TBD: List these alphabetically.

  1. ITSEC
  2. Brian Proffitt, DistributionWatch Review: SmoothWall Linux 0.9.4: A Secure Distribution, http:// www. linuxplanet.com/ linuxplanet/ reviews/ 2341/ 1/, March 30, 2001.
  3. Marcel Gagné, The e-smith server and gateway,  12-June-2001
  4. LKAP: A Manifesto for a Secure Linux Kernel Audit, http://mail.nl.linux.org/kernel-audit/, http://www.lkap.org/mission.html  
  5. List of Linux Distributions, http://kernelnotes.org/dist-index.html 
  6. Linux Firewall and Security Site, http://www.linux-firewall-tools.com/linux/ 
  7. The linux-security-module Archives, http://mail.wirex.com/pipermail/linux-security-module/ 
  8. VXE - Virtual eXecuting Environment, http://www.intes.odessa.ua/vxe/ 
  9. Bastille-Linux Scripts to Secure Linux, http://www.sans.org/newlook/projects/bastille_linux.htm  
  10. Seán Boran, Hardening Solaris, October 25, 1999, http://securityportal.com/cover/ coverstory19991025.html  .
  11. Michael Espinala, "The Hardening of Microsoft Windows NT Operating System Version 4.0", March 1998.  Proper configuration, actually. 
  12. Seán Boran, Hardening Solaris, October 25, 1999, http://securityportal.com/cover/ coverstory19991025.html  Reference.
  13. Crispin Cowan, Steve Beattie, Chris Wright, and Greg Kroah-Hartman, RaceGuard: Kernel Protection From Temporary File Race Vulnerabilities, 10th USENIX Security Symposium, August 13–17, 2001.
  14. Andreas Grünbacher, Extended Attributes and Access Control Lists for Linux, http://acl.bestbits.at/, 28 October 2001
  15. Xie Huagang and Nick DeClario, Build a Secure System with LIDS, http://www. linuxsecurity. com/ feature_stories/ feature_story-12.html, May 2000.
  16. Mike Frantzen, Cerias, and Mike Shuey, "StackGhost: Hardware Facilitated Stack Protection," 10th USENIX Security Symposium, August 13–17, 2001.
  17. Capabilities FAQ, ftp://ftp.guardian.no/pub/free/linux/capabilities/capfaq.txt
  18. Immunix OS http://www.wirex.com/  http://immunix.org.  Carefully re-compiled RedHat distribution. 
  19. Janus, http://www.cs.berkeley.edu/~daw/janus/ Janus is a security tool for sandboxing untrusted applications within a restricted execution environment. This can be used to limit the harm that can be caused by any successful compromise of the application. We have successfully used Janus to jail Apache, bind, and other programs within a limited sandbox without disturbing application behavior, and we continue to seek experience with using this approach in production environments.
  20. Prabhaker Mateti, Configuring a System Properly, Lecture Notes on Internet Security, July 2001,  http://www.cs.wright.edu/ ~pmateti/ Courses/ 429/ Config/ index.html
  21. Prabhaker Mateti, Configuring a System Properly, http://www.cs.wright.edu/~pmateti/Courses/429/Config/index.html, Wright State University, Spring 2001
  22. Prabhaker Mateti, Security Fortification, http://www.cs.wright.edu/~pmateti/Courses/429/Fortification/index.html,  Wright State University, Spring 2001
  23. Prabhaker Mateti, Secured Distributions of Linux, working draft,  Wright State University, October 2001.
  24. Prabhaker Mateti, Hardening an Operating System, Lecture Notes on Internet Security, July 2001, Wright State University. http://www.cs.wright.edu/~pmateti/Courses/429/HardenOS/index.html Required Reading.
  25. Jon Lasser,, and Jay Beale, Bastille-Linux Scripts to Secure Linux, http://www.sans.org/newlook/projects/bastille_linux.htm, June 2001.
  26. Terrence Mitchem, Raymond Lu and Richard O'Brien, "Kernel Hypervisors, Using Kernel Hypervisors to Secure Applications," Annual Computer Security Application Conference (ACSAC 97),  December 1997, http://www.securecomputing.com/khyper/
  27. NSA, SE Linux http://www.nsa.gov/selinux/
  28. REMUS Project: REference Monitor for Unix Systems, http://twiki.dsi.uniroma1.it/twiki/view/Remus/WebHome
  29. R. Spencer, S. Smalley, P. Loscocco, M. Hibler, D. Andersen, and J. Lepreau, "The Flask Security Architecture: System Support for Diverse Security Policies,"  Proceedings of the Eighth USENIX Security Symposium, pp. 123-139, Aug. 1999.
  30. Vyacheslav Zavadsky, Linux Trustees, http://trustees.sourceforge.net/
  31. Andrew G. Morgan, Linux-Privs,  http://www.linuxsecurity.com/resource_files/server_security/linux-privs/ linux-privs.html
  32. LCAP - Linux Kernel Capability Bounding Set Editor, http://pweb.netcom.com/~spoon/lcap/
  33. Pragmatic, "(nearly) Complete Linux Loadable Kernel Modules: The definitive guide for hackers, virus coders and system administrators," http://www.thehackerschoice.com/papers/LKM_HACKING.html, March 1999.
  34. David Larochelle and David Evans. Statically Detecting Likely Buffer Overflow Vulnerabilities. In 2001 USENIX Security Symposium, Washington, D. C., August 13-17, 2001. (PDF, HTML, 13 pages)
  35. Matthew Smart, G. Robert Malan, and Farnam Jahanian, University of Michigan, "Defeating TCP/IP Stack Fingerprinting," August 2000, http://www.usenix.org/publications/library/proceedings/sec2000/smart.html.
  36. Antony Edwards, Trent R. Jaeger, Xiaolan Zhang, "Verifying Authorization Hook Placement for the Linux
    Security Modules Framework, IBM Tech Report RC22254 November 2001.
 
Copyright © 2004 pmateti@cs.wright.edu 01/26/02 12:30:41 PM