Linux Enterprise Security Projects
There are quite a number of projects underway to improve the overall acceptance of Linux as a secure, enterprise- class operating system. The following is a brief introduction to the leading efforts in various areas of Linux security:

Linux Kernel Auditing Project
The LKAP has as its goal a non-intrusive security audit of the Linux kernel code "without affecting/breaking/disrupting any other part of the kernel." Begun by Bryan Paxton, it has recently been taken on by Aaron Grothe. Current needs include auditing the 2.4 series of the kernel, compiling a list of useful security tools, documentation, and home page editing including a browseable version of the current kernel code being audited.

Linux Security Module
The Linux Kernel Summit identified a need to extend the module interface to allow for security modules. Many Linux security projects now require that the system administrator patch and recompile the kernel to achieve the desired se-curity. The Linux Security Module effort would enable the security products to be delivered as loadable modules and eliminate the need to recompile the kernel. http://lsm.immunix.org/

User-Mode Linux
User-Mode Linux is a safe, secure way of running Linux versions and Linux processes. Run buggy software, experiment with new Linux kernels or distributions, and poke around in the internals of Linux, all without risking your main Linux setup. User-Mode Linux gives you a virtual machine that may have more hardware and software virtual resources than your actual, physical computer. Disk storage for the virtual machine is entirely contained inside a single file on your physical machine. You can assign your virtual machine only the hardware access you want it to have. With properly limited access, nothing you do on the virtual machine can change or damage your real computer, or its software. The user-mode authors enumerate some uses for User-Mode Linux:

• Kernel development and debugging
• Safely evaluating the latest kernels
• Trying out new distributions
• Experimental development and code isolation
• Examining and debugging a running system
• As a secure sandbox or jail
• Virtual networking
• As a test environment
• Disaster recovery practice and recovery-tools testing
• A Linux environment for other operating systems
• Virtual hosting

LIDS: Linux Intrusion Detection System
The Linux Intrusion Detection System is a patch and set of administration tools which enhance the kernel’s security. It implements a reference monitor and Mandatory Access Controls in the Linux kernel. When in effect, chosen files access, every system or network administration operation, any capability use, raw device, memory or I/O access can be made impossible even for root. It uses and extends the system capabilities bounding set to control the entire system and adds some network and file-system security features in the kernel to enhance the security. You can finely tune the security protections online, hide sensitive processes, receive security alerts through the network, and more. In short, with the security model implementation in the kernel, LIDS provides Protection, Detection and Response in the Linux system.

SNORT
Snort is a lightweight network intrusion detection system, capable of performing real-time traffic analysis and packet logging on IP networks. It can perform protocol analysis, content searching/matching and can be used to detect a variety of attacks and probes, such as buffer overflows, stealth port scans, CGI attacks, SMB probes, OS fingerprinting attempts, and much more. Snort uses a flexible rules language to describe traffic that it should collect or pass, as well as a detection engine that utilizes a modular plug-in architecture. Snort has a real-time alerting capability as well, incorporating alerting mechanisms for syslog, a user specified file, a UNIX socket, or WinPopup messages to Windows clients using Samba’s smbclient. Snort has three primary uses. It can be used as a straight packet sniffer like tcpdump, a packet logger (useful for network traffic debugging, etc), or as a full blown network intrusion detection system.

RSBAC: Role-Set Based Access Control
RSBAC is an open source security extension for current Linux kernels. It is based on the Generalized Framework for Access Control (GFAC) by Abrams and LaPadula and provides a flexible system of access control based on several modules. All security relevant system calls are extended by security enforcement code. This code calls the central decision component, which in turn calls all active deci-sion modules and generates a combined decision. This decision is then enforced by the system call extensions. Decisions are based on the type of access (request type), the access target and on the values of attributes attached to the subject calling and to the target to be accessed. Additional independent attributes can be used by individual modules, e.g. the privacy module (PM). All attributes are stored in fully protected directories, one on each mounted device. Thus changes to attributes require special system calls provided. As all types of access decisions are based on general decision requests, many different security policies can be implemented as a decision module.

SELinux: NSA Security-Enhanced Linux
The release of the National Security Agency’s existing work on securing Linux under the GNU Public License has caused quite a stir in the security nity. The opportunity to work openly with some of the top minds in the NSA has been embraced both by the open-source community and those within the NSA. For an overview of the NSA’s commitment, see the press release. End systems must be able to enforce the separation of information based on confidentiality and integrity requirements to provide system security. Operating system security mechanisms are the foundation for ensuring such separation. Unfortunately, existing mainstream operating systems lack 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. To address this problem, the National Security Agency’s Information Assurance Research Office is integrating a flexible mandatory access control architecture known as Flask into the Linux operating system. Researchers at the NSA have implemented the architecture in the major subsystems of the Linux kernel, including mandatory access controls for operations on processes, files, and sockets. The Secure Execution Environments (SEE) group at NAI Labs is working with the NSA in further developing and configuring this Security-Enhanced Linux operating system. The SEE group is developing a Role-Based Access Control and Type Enforcement security policy configuration for the base system. They are also designing and implementing mandatory access controls for additional kernel components. Researchers at Secure Computing Corporation and MITRE have contributed to the development of enhanced utility programs and application security policies. The Security-Enhanced Linux provides strong, flexible controls that can support the following:

• Separation of information based on confidentiality and integrity requirements,
• Protection against unauthorized modification or disclosure of data,
• Protection against tampering with the kernel or applications,
• Protection against bypassing application security mechanisms,
• Protection against the execution of un-trustworthy programs,
• Protection against interference with other processes, and
• Confinement of the potential damage caused by malicious or flawed programs.

Stack Guard
StackGuard is a compiler approach for defending programs and systems against "stack smashing" attacks. Stack smashing attacks are the most common form of security vulnerability. Programs that have been compiled with StackGuard are largely immune to stack smashing attack. Protection requires no source code changes at all. When a vulnerability is exploited, StackGuard detects the attack in progress, raises an intrusion alert, and halts the victim program.

Packet Filtering: ipfwadm, ipchains, iptables
Linux has enjoyed a progression of different fire-walling code, roughly on the same time-line as major releases of the kernel. Linux 2.0 brought us ipfwadm, the first iteration of packet filtering. Linux 2.2 improved upon this with ipchains. The latest and definitely greatest implementation comes adapted from the OpenBSD community - iptables. This new revision ships with kernel 2.4.0, and implements many new features. Fear not, however, as 2.4.0 includes backward-compatibility for ipchains and even ipfwadm. To explain why you should be interested in ipt-ables, AKA NetFilter, here is a quote from a recent article in SecurityPortal – an online resource for Linux security:

Technical Summary

It’s also much easier to manage. Net filter’s architecture allows much easier and more powerful configuration of network address translation (NAT), transparent proxies, and redirection. This latter function allows for easier load-sharing server clustering, i.e., replacing one Web server transparently with four. Further, NetFilter blocks more DoS attacks by intelligently rate limiting user-defined packet types, allowing you to block attacks like SYN floods.

NetFilter is a re-implementation of Linux’s firewalling code, but remains very backward-compatible. This should shorten most organizaions’ migration time and keep the cost in time and training relatively low.

LOMAC
LOMAC is a security enhancement for Linux that uses Low Water-Mark Mandatory Access Control to protect the integrity of processes and data from viruses, Trojan horses, malicious remote users, and compromised root daemons. LOMAC is implemented as a loadable kernel module - no kernel recompilations or changes to existing applications are required. Although some features and fixes remain to be implemented, LOMAC presently is stable enough for everyday use. From the web page:

LOMAC is an attempt to make an easily-adoptable form of MAC integrity protection available to the Free UNIX community without the discouraging necessity of kernel modifications. LOMAC implements a simple form of MAC integrity protection based on Biba’s Low Water-Mark model in a Linux Loadable Kernel Module (LKM). Although it trades off some of the advanced MAC features found in traditional MAC implementations, LOMAC provides useful integrity protection without any modifications to the kernel, applications, or their existing configurations. LOMAC is designed to be compatible with existing software, and ships with a one-size-fits-all default configuration. LOMAC may be used to harden currently-deployed Linux systems simply by loading the LKM into the kernel shortly after boot time.

Once loaded, LOMAC divides the system into two conceptual levels of integrity: high and low. The high side contains all process and files that should be protected from malicious code and remote users: the kernel servers (kflushd and friends), the system binaries (bin,lib), the system configuration files (etc), and any mission-critical data (your web pages). The low side contains the processes that interact with remote users (remote login sessions, httpd) and the files they down-load from the net (mail attachments). Low files may contain viruses or Trojan Horses. Low processes take input from remote users that may cause buffer overflows. During runtime, LOMAC protects high files and processes by preventing low processes from modifying or signaling them. Thanks to is generic default configuration, LOMAC handles the division of the system into high and low parts automatically, without administrative direction.

LOMAC does not override the existing Linux protection mechanisms. Instead, its permission checks are done in addition to the existing ones - the kernel permits an operation only if both the existing mechanisms and LOMAC decide it should permit it. Unlike the existing Linux protection mechanisms, LOMAC makes decisions based solely on integrity level, not on user identity. With LOMAC, a low-level root process is just as powerless as a low-level non-root process. Since LOMAC automatically places all network servers in the low part of the system, this fact prevents compromised root-privileged network servers from harming the high-integrity part of the system.

PortSentry
PortSentry is part of the Abacus Project suite of security tools. It is a program designed to detect and respond to port scans against a target host in real-time. Some of the more useful features include:

• Runs on TCP and UDP sockets to detect port scans against your system.
PortSentry is configurable to run on multiple sockets at the same time so you only need to start one copy to cover dozens of services.
• Stealth scan detection (Linux only right now). PortSentry will detect SYN/half-open, FIN, NULL, X-MAS and oddball packet stealth scans. Four stealth scan operation modes are available for you to choose from.
• PortSentry will react to a port scan attempt by blocking the host in real-time. This is done through configured options of either dropping the local route back to the attacker, using the Linux ipfwadm/ipchains command, *BSD ipfw command, and/or dropping the attacker host IP into a TCP Wrappers hosts.deny file automatically.
• PortSentry has an internal state engine to remember hosts that connected previously. This allows the setting of a trigger value to prevent false alarms and detect "random" port probing.
• PortSentry will report all violations to the local or remote syslog daemons indicating the system name, time of attack, attacking host IP and the TCP or UDP port a connection attempt was made to. When used in conjunction with LogCheck[17] it will provide an alert to administrators through e-mail. Once a scan is detected your system will turn into a black hole and disappear from the attacker. This feature stops most attacks cold.

TCFS
TCFS is a Transparent Cryptographic File System that is a suitable solution to the problem of privacy for distributed file system. By a deeper integration between the encryption service and the file system, it results in a complete transparency of use to the user applications. Files are stored in encrypted form and are decrypted before they are read. The encryption/decryption process takes place on the client machine and thus the encryption/decryption key never travels on the network.

The TCFS version 3.0b-p1 is the latest TCFS version and was released on January 22, 2001.

TCFS is based on Matt Blaze’s Cryptographic File System.

Acknowledgments Many thanks to Lee Terrell, Dave Littlewood, Hubertus Franke, Ralph Christ, Mary Ann Fisher, Andreas Hermelink and especially Frank Martin for their input and comments.

Note: All trademarks and copyrights are the property of their respective holders.