Securing your system with Linux Intrusion Detection System
Closing the Lid

© Bratscher, photocase.com
If you're ready for mandatory access control and you're looking for an alternative to SELinux and AppArmor, try locking down your system with Linux Intrusion Detection System.
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."
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).
Buy Linux Magazine
Direct Download
Read full article as PDF:
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Find SysAdmin Jobs
News
-
MNT Seeks Financial Backing for New Seven-Inch Linux Laptop
MNT Pocket Reform is a tiny laptop that is modular, upgradable, recyclable, reusable, and ships with Debian Linux.
-
Ubuntu Flatpak Remix Adds Flatpak Support Preinstalled
If you're looking for a version of Ubuntu that includes Flatpak support out of the box, there's one clear option.
-
Gnome 44 Release Candidate Now Available
The Gnome 44 release candidate has officially arrived and adds a few changes into the mix.
-
Flathub Vying to Become the Standard Linux App Store
If the Flathub team has any say in the matter, their product will become the default tool for installing Linux apps in 2023.
-
Debian 12 to Ship with KDE Plasma 5.27
The Debian development team has shifted to the latest version of KDE for their testing branch.
-
Planet Computers Launches ARM-based Linux Desktop PCs
The firm that originally released a line of mobile keyboards has taken a different direction and has developed a new line of out-of-the-box mini Linux desktop computers.
-
Ubuntu No Longer Shipping with Flatpak
In a move that probably won’t come as a shock to many, Ubuntu and all of its official spins will no longer ship with Flatpak installed.
-
openSUSE Leap 15.5 Beta Now Available
The final version of the Leap 15 series of openSUSE is available for beta testing and offers only new software versions.
-
Linux Kernel 6.2 Released with New Hardware Support
Find out what's new in the most recent release from Linus Torvalds and the Linux kernel team.
-
Kubuntu Focus Team Releases New Mini Desktop
The team behind Kubuntu Focus has released a new NX GEN 2 mini desktop PC powered by Linux.