Next Previous Contents

4. Configure the LIDS system

In this chapter, we will show you how to configure the lids.

4.1 LIDS configuration directory -- "/etc/lids/"

After install lidsadm, you can find that it creates a lids configuration directory in /etc/lids/. When the kernel booting up, the configuration info will be read into the kernel to initial the LIDS system.

4.2 Protect files and directories.

Firstly, you must determine which files you will protect. In most case, you may protect the system binary files and system configuration files, such as /usr/, /sbin/, /etc/, /var/log/.

Secondly, you must decide the way to protect the files. LIDS provide 4 protection type:

DENY access to any body.

The file or directory marked as DENY means that nobody can see or modify it. The most sensity file should be configurate as DENY. For example, we can make /etc/shadow as DENY access to anybody,

        lidsadm -A -o file_to_protected -j DENY

# lidsadm -A -o /etc/shadow -j DENY
After reboot or RELOAD the configurate files. you can see,
# ls /etc/shadow
ls: /etc/shadow: No such file or directory

After then, you can make some program can access to the files, for example, when login to the system, the /bin/login file need to read the password from the protected file /etc/shadow, but it has been labeled as DENY, so you can do,

# lidsadm -A -s /bin/login -o /etc/shadow -j READ  

After the configurate is in effect * reboot the system of RELOAD the configure file) , you can login onto the system but you can not access the /etc/shadow using other command. It is an example of MAC(mandatory access control).

Read Only Files.

The files marked with Read Only means that nobody can change the files. We can think that the following files are in this catalog, /etc/passwd, /bin/passwd, etc.

lidsadm -A -o file_to_protect -j READ 


1. to protect the whole /sbin/ as read-only.

 # /sbin/lidsadm -A -o /sbin/ -j READ

2. to protect /etc/passwd as read-only

 # /sbin/lidsadm -A -o /etc/passwd -j READ

Append Only Files.

Most of the append only files are system log files, such as /var/log/message ,/var/log/secure. The files can only open with append mode and can not truncate or modify its previous contents.

lidsadm -A -o filename_to_protect -j APPEND


1. to protect the system log files

# /sbin/lidsadm -A -o /var/log/message -j APPEND
# /sbin/lidsadm -A -o /var/log/secure -j APPEND

2. to protect the apache httpd log files

# /sbin/lidsadm -A -o /etc/httpd/logs/ -j APPEND


This type used to define an object can be write to a subject.

Mandatory Access Control in file protection

You can define which subject ( program) can access which object(files) with what kind of access mode - READ, APPEND, WRITE.

For example, you can define /home/httpd/ as DENY to anybody and let /usr/sbin/httpd can READ from that directory. In this case, the Web Server can serve as public WEB Server as normal but the contect and program under the /home/httpd/ can not be seen or modified. If the intruder can get the root shell by the security bugs in httpd, he can not even seen the files in the root shell. Even if he can insert some dangerous code in the httpd server by overwrite the stack, he can only read the file under /home/httpd but he can not modified it.

# lidsadm -A -o /home/httpd -j DENY
# lidsadm -A -s /usr/sbin/httpd -o /home/httpd -j READ


Here is the example from LIDS HOWTO by Philippe Biond,

lidsadm -Z
lidsadm -A -o /boot -j READ
lidsadm -A -o /vmlinuz -j READ
lidsadm -A -o /lib -j READ
lidsadm -A -o /root -j READ
lidsadm -A -o /etc -j READ
lidsadm -A -o /sbin -j READ
lidsadm -A -o /usr/sbin -j READ
lidsadm -A -o /bin -j READ
lidsadm -A -o /usr/bin -j READ
lidsadm -A -o /usr/lib -j READ
lidsadm -A -o /var/log -j APPEND 

An example lids.conf came with lidsadm package in /etc/lids/ after you install lidsadm, you must run "lidsadm -U" to update the inode/dev value and re-configrate it to fit you requirement.

4.3 Protect processes.

UN-killable process

LIDS can protect the process whose parent is init(pid=1), you must configurate the capability (/etc/lids/lids.cap) as below.


hidden process

You label the process as HIDDEN, so when the process startup, it can not be found by anybody used "ps" or in "/proc".

        lidsadm -A -s /usr/sbin/httpd -t -o CAP_HIDDEN -j INHERIT

4.4 Protect with capability.

Capabilities are like privileges you can give a process. A root process has all the capabilities. But there exists a capabilities bounding set. In a normal kernel, when you remove a capability from the bounding set, nobody can ever use it again, until next reboot. (see spoon/lcap for the normal use).

LIDS modifies this behavior to enable you to switch theses on and off, whenever you want. An access to the /proc/sys/kernel/cap_bset is trapped and raise a security alert. lidsadm performs all the job.

You can list all capability in LIDS by running lidsadm, and you can see what the exactly meaning of each capability.

system capability configuration.

The system capability value is stored in /etc/lids/lids.cap. You must edit the file to fit your requirement.

We here discuss two of them,

Configurate the lids.cap.

we can enable a capability to set "+" in front of the capability name or "-" to disable the capability.

### 0: In a system with the _POSIX_CHOWN_RESTRICTED option defined, this overrides the restriction
### 0: of changing file ownership and group ownership.

### 1: Override all DAC access, including ACL execute access if _POSIX_ACL is defined. Excluding
### 1: DAC access covered by CAP_LINUX_IMMUTABLE.

The example above is to set CAP_CHOWN to disable(-) and enable the CAP_DAC_OVERRIDE(+). You should check the file (lids.cap) carefully to determine which capability you will use and which you will not use.

Labeling individual process with capabilities.

You can labeling process with capability to make the process capable to do something that the system capability has been disable.

For example, you can make CAP_SYS_RAWIO as disable(-) in /etc/lids/lids.cap. But you still need to use X Server which must use this capability to start it. so you can do

# lidsadm -A -s /usr/X11R6/bin/XF86_SVGA -t -o CAP_SYS_RAWIO -j INHERIT
to make XF86_SVGA has the capability of CA_SYS_RAWIO while other program is unable to obtain the CAP_SYS_RAWIO.

Sealing the kernel

After booting the kernel, the system capability is not in effect until you seal the kernel. you *MUST* add the following line in /etc/rc.d/rc.local in RedHat System or other bootup initial file in other system,

#/sbin/lidsadm -I

4.5 Network Security.

LIDS provide some network security enhancement.

network security with capability

With the capability, we can enhance the network security. such as anti snifferring, can not bind to the port lower than 1024, can not change the firewall and routing rules.

so, what I suggest is to view each capability meaning carefully.

Scanner detector in kernel

LIDS provide a scanner detector in kernel in order to detect who had scan your system. The scanner can detect half-open scan, SYN stealth port scan, Stealth FIN, Xmas, or Null scan,etc. Tools like nmap, satan can be detected by the detector.

It is useful when raw socket is disable. In this case, some user space detector based on snifferring will not work. And the detector does not use any socket, it will be more secure than a user space detector.

If you want this feature, you should select it on when compile the kernel.

4.6 Intrusion Responsive system.

When LIDS detect some thing violate the rules defined, it can response to the action by following method.

Logging the message

When someone violate rules, lids_security_log will log a message the klogd, the logging also have the ability to anti_logging_flood. You can set it when compile the kernel.

Logging the message via mail server

Now, LIDS has a new feature to mail the message to your mail account. you can define the mail server IP, the out-coming mail address,etc, in the /etc/lids/, more detail please refer to that file.

Here is an example


# MAIL_RELAY=hex IP:port
# IP11.1 of the machine that will be directly connected by LIDS
# for relaying its mails. Port is usually 25, but who knows...

# MAIL_SOURCE=source machine :
# Name of the source machine, used for the ehlo identification.
# Note that a bad name here could make the mail relay refuse your
# mails.

In this example, the SMTP server to relay the server is, port 25. The mail source is used for EHLO identification.

Handup the console

When user violate the rules, the console will shutdown the user's console.

Next Previous Contents