Author: Preston St. Pierre
You may be wondering why anyone would choose LIDS over its more popular counterpart, SELinux. Both have their advantages. Both add MAC and the ability to limit the damage that can be done by the root account. There are two reasons why you may want to consider LIDS instead of SELinux.
First, LIDS is easier to implement on a wide range of Linux distributions. This is because LIDS ACLs are easier to configure than SELinux policies. SELinux policies are notoriously hard to implement correctly. For many distributions, using SELinux will not be a realistic choice unless they ship with pre-defined SELinux policies.
Second, LIDS does not contain any patented technologies. SELinux makes use of a technology known as Type Enforcement(TE). TE is patented by Secure Computing Corporation(SCC). Although SCC has pledged not enforce its patent against users of SELinux, it refuses to make this a condition for sale of the patent. In other words, if SCC sells the patent, the new owner could sue anyone using SELinux for patent infringement. That is just the most alarming clause. View their “statement of assurance” and decide for yourself.
One advantage SELinux has is its ability to split administrative privileges up with Role Based Access Control(RBAC), a feature LIDS lacks. However, this feature will not find its way into distributions for some time. It is even disabled in Red Hat Enterprise 4, the only production ready distribution that ships with pre-defined SELinux policies.
Getting Started
To install LIDS, follow the directions included in the download. Instructions are included for patching the kernel and installing the administration utilities. For maximum security, compile LIDS directly into the kernel instead of installin it as a module.
LIDS protects your system in two ways. First, it reigns in the power of the root account. This is done by limiting the root account’s capabilities. Second, it protects specific files and processes with ACLs. Let us start with capabilities and then take a look at ACLs.
Capabilities were added to the Linux kernel to help solve the problem of needing full root privileges to perform even simple tasks. Capabilities break down the power of root into a set of fine-grained privileges. They range from disabling the tradition Discretionary Access Control (DAC) model to preventing the system from being rebooted. Currently, there are 28 capabilities in the kernel. LIDS adds two of its own.
Begin by deciding what capabilities LIDS will enforce.
You set the capabilities by modifying the file /etc/lids/lid.cap. Those preceded by a – are disabled. Here is an example, showing both an enabled and disabled capability from the default installation:
### 29: Restricts viewable processes by a user.
#
+29:CAP_HIDDEN
### 30: Allow killing protected processes.
#
-30:CAP_KILL_PROTECTED
The truly paranoid will want to become familiar with all of the capabilities. However, the default settings will be appropriate for most networked servers.
Set up the ACLs
Controlling files and processes with ACLs is the heart of LIDS. The lidsconf utility configures the ACLs. Use it to enable or disable specific capabilities (from lids.cap) and set the following options:
- DENY — deny access
- READONLY — read only
- APPEND — append only
- WRITE — writable
- GRANT — grant capability to subject
- IGNORE — ignore any permissions set on this object
- DISABLE — disable a capability
Lidsconf uses a subject and object syntax. Subjects can be programs only; objects can be anything a program accesses, such as files, directories, capabilities, and sockets.
Let’s take a look at a few sample ACLs:
lidsconf -A -s /bin/yourprogram -o /etc/yourconfigfile -j READONLY
Here, lidsconf adds (-A) an access control that grants the subject (-s) yourprogram READONLY privileges to the object (-o) yourconfigfile. This means that yourprogram cannot delete or write to yourconfigfile even if running with root privileges.
lidsconf -A -o /some/fileordirectory -j READONLY
In this example, since there is no subject defined (no -s argument)F, the rule does not apply to a specific program. This rule makes a file or directory read-only for all users and processes. When a directory is the object, all of the files inside of it are made read-only.
To delete this example, use:
lidsconf -D -o /some/fileordirectory -j READONLY
This final example takes a look at using a capability as an object:
lidsconf -A -s /usr/local/apache/bin/httpd -o CAP_NET_BIND_SERVICE 80 -j GRANT
Here the subject (-s) is the Apache Web server. The object (-o) CAP_NET_BIND_SERVICE controls the binding of privileged ports. If you have globally disabled this capability in /etc/lids/lids.cap to stop unauthorized network access, you need to specify which programs can bind to privileged ports on a one-on-one basis. This rule grants Apache the ability to bind to port 80.
To make life easier, the LIDS project provides predefined ACLs for the following programs:
- Apache
- MySQL
- Samba
- OpenSSH
- OpenLDAP
- djbdns
- Qmail
- IMAP
You can copy an paste these ACLs into your system’s start-up scripts. You may need to tweak them depending on how your distribution installs these programs. Use these settings as a guide and adjust them to meet your requirements. The FAQ also includes a sample script to secure key system files and libraries.
After setting up the ACLs, point them to the correct inode value and install them with:
lidsconf -Ulidsconf -C
To view a list of your ACLs, use the command:
lidsconf -L
Running LIDS
You administer LIDS with the lidsadm utility. You will use lidsadm to:
- seal the kernel
- start and stop LIDS sessions
- reload configuration files
- view the status of capabilities
For maximum security, seal the kernel at boot by placing the command:
lidsadm -I
in your distribution’s startup scripts (rc.local will usually do). If you don’t, then after you reboot, LIDS will enforce its ACLs but not its capabilities.
At this point, you can reboot your system at any time into your LIDS enabled kernel and it will be fully protected.
Now let’s take a look at some common administration tasks.
Once LIDS is enabled, the only way to change capabilities, ACLs, or configuration files, is to start a LIDS Free Session(LFS) with:
lidsadm -S -- -LIDS
This prompts for the LIDS password set during installation. After making changes, update the ACLs and reload the configuration files with the commands:
lidsconf -Clidsadm -S -- +RELOAD_CONF
To re-enable LIDS on this terminal use:
lidsadm -S -- +LIDS
You can enable or disable LIDS system-wide by substituting the switch LIDS_GLOBAL for LIDS.
To view which capabilities are enabled and disabled, use:
lidsadm -V
Finally, to boot into your LIDS kernel with LIDS disabled, pass the argument:
lids=0
to your boot loader.
Although LIDS may seem daunting at first, once you understand the concept of capabilities and the syntax of its ACLs, you are well on your way to a more secure system. Don’t view LIDS as a catch-all solution, but rather as an added layer of protection for your server. The more defenses an intruder has to penetrate, the better.
For more information, visit the wiki.
