Closing the Lid

Conventional Linux security gives an all-powerful user access to the entire system. The Linux root user has the power to do anything and everything. This design has led to a number of issues. For instance, an intruder who gains the root password or forces a root-level application to crash can quickly get control of the whole system. Also, many threats come from within, and managers often worry about who is watching the watchers. In these environments, it makes sense to limit the privileges of the root user.

Developers have rolled out several solutions over the years that supplement the conventional Unix discretionary access controls with a system of mandatory access control. Mandatory access control systems such as SELinux [1] and AppArmor [2] provide several benefits, including the chance to limit the activities of root.

Another security solution offering mandatory access control for Linux is the Linux Intrusion Detection System (LIDS) [3]. LIDS has been around for several years, and the developers continue to update it for new kernel versions (although the documentation is due for an upgrade). The latest version supports Linux kernel 2.6.28.

LIDS is a kernel patch, along with a couple of utilities, that implements a number of security features. When implemented correctly, LIDS can dramatically increase your system's security.

Under the LID

Like other mandatory access control systems, LIDS goes beyond the simple user/group/other permissions to support much finer control over who can access a particular file or directory and what they can do with it. For example, you can give access to a directory to someone who is neither the owner nor a member of the group. Access to an object is defined through an Access Control List (ACL). Several Linux tools implement various forms of ACLs. In addition to protecting files and directories, LIDS applies a kind of ACL-based access control to processes. For example, you can prevent a process from changing permissions on a file, even if it normally has that right. LIDS implements a system of capabilities that controls a user's access to process-related privileges (see Table 1). If a capability is disabled, it does not matter what rights the file permissions and ownership would normally allow it – LIDS will stop you from carrying out the task.

The LIDS ACLs are integrated into the Virtual File System (VFS) layer, so you can use them on any filesystem, regardless of whether the system supports ACLs natively or not. LIDS ACLs are not stored on the actual filesystem but in files in the /etc/lids directory. You can even configure the system to access ACLs on remotely mounted filesystems using Samba or NFS.

LIDS offers a number of other security benefits, including:

• Trusted Path Execution (TPE) – Traditional TPE means that no one but root can alter the path to a particular executable or alter that executable itself. LIDS takes this one step further in specifying that even root's access is restricted. Keep in mind that it is not just the familiar commands and applications that have executable code. Both libraries and modules also contain executable code that must be checked before they are allowed to run.
• Trusted Domain Enforcement (TDE) – TDE states that, when a program runs, it does so either in an trusted or untrusted "domain." Because the kernel knows the privilege level of both the program and the input, it reacts accordingly when an application gets input from a source with a lower privilege level. At this point, the kernel then treats the program as having the lower privilege level. You can override TDE with the CAP_PROTECTED capability, which allows programs to read unprotected data and still remain at a higher privilege level.
• Application Sandboxing – Sandboxing restricts the movement of the specific application (similar to chroot). Should the program have bugs or security holes, sandboxing limits the scope of any damage. LIDS also maintains these boundaries for all child processes.
• Sealing the kernel – Conventional Linux lets the root user add or update drivers and other functionality while the system is running. This powerful feature means that a nefarious system administrator (as well as some malware programs) can significantly alter the system without attracting attention. To prevent this, you need to prevent the root user from adding modules. "Sealing the kernel" ensures that no modules can be added to the running system. Once the kernel is sealed, the behavior of the system is controlled by the ACLs.

The security enhancements provided with LIDS will help you keep intruders away, however, you should be aware of the extent to which LIDS restricts access and be prepared for any disruption to your environment. For instance, one of the key benefits of LIDS is preventing the execution of untrusted code. If you are working in a development environment in which you are constantly compiling different programs, the compiled programs might not run correctly when LIDS restricts their access.

Getting and Installing LIDS

LIDS is a Linux kernel patch that you need to compile and install on your system. In that it is a kernel patch, each version of LIDS applies to a specific kernel version, So when you download the source code [3], make sure you have the version for your specific kernel.

Notes in several places exhort you to compile LIDS using the source code for a specific distribution. Possibly the developers of the distribution you are using made changes to the kernel source so the patch doesn't work correctly. The solution is to download the source code for a fresh, "vanilla" kernel and compiled that.

Installing LIDS on a production machine is potentially dangerous. Anytime you tinker with the kernel, problems can occur, so you need to follow normal safety precautions to ensure you can boot from previous kernels. If the kernel boots properly, but you have other problems, turn off LIDS at boot time by adding lids=0 to the boot string.

To get a working LIDS system without installing the patch and rebooting, download one of the VMware images [4]. These images even work with free VMware versions.

I downloaded and compiled using a 2.6.28 kernel. In addition to my new compiled kernel version, I worked with a CentOS version running a 2.6.9 Kernel with lids-2.2.2, which I downloaded as a VMware image. For details of the various compile options, I point you to the documentation provided with the LIDS source code. Implementing the patch and making any changes to your existing kernel configuration is documented well enough that I won't go into the details here. Some LIDS features need to be enabled when the kernel is compiled: otherwise, they will not be available. See the documentation that comes with the source code for more details.

Basic LIDS Configuration

The /etc/lids directory contains the LIDS configuration files. Note that, once LIDS is running, this directory is inaccessible to all users, including root. Several configuration files reside in this directory, some of which apply only to specific LIDS states. See the box titled "Primary LIDS Configuration Files."

The .cap files contain the capability definitions. The .conf files are files that describe the ACL configuration. If a configuration file references a particular state (i.e., boot), it applies only to that state.

Using the lids.net file, you can configure LIDS to send alerts when specific security-related events occur on the network. I was not able to find any method of sending a notification other than email, nor could I find any apparent way of defining the events for which a message is sent. However, this problem is not too hard to overcome because the access violations are written to syslogd and thus to the messages file. You could configure a log parser to read the log and send a message with the use of another notification mechanism (e.g., you could send it to Nagios).