Lids linux intrusion detection system

Getting Started with the Linux Intrusion Detection System

With increasing usage of Linux in various computing environments, a lot of security vulnerabilities are being discovered in GNU/Linux-based systems. Due to the open nature of application development in the Open Source world, a lot of vulnerabilities are being addressed very quickly. But, it may happen that a patch is not addressed in a timely manner, and in the meantime, all the systems running the application are exposed. Malicious users can possibly gain root privileges and wreak havoc with these systems. This is where the Linux Intrusion Detection System (LIDS) comes to the rescue.

LIDS is a patch to the Linux kernel; it implements access control and a reference monitor. LIDS is configured with its two admin tools, lidsconf and lidsadm.

lidsadm is the utility that allows you to disable LIDS in a terminal, so that you can set various settings, which LIDS, when enabled, won’t allow you to do, and you can view the current status of your LIDS installation with this tool.

lidsconf is the tool that allows you to add and remove access control to certain files, which can be binaries or any other files. LIDS refers to these files as objects, and the capabilities we allow or disallow are referred to as subjects. LIDS overrides things like filesystem permissions. You can literally use LIDS to make it impossible to access virtually any object, whether it’s a file, raw device, memory or I/O, even if you’re trying to access the object as the root user.

In short, LIDS is a complete security model implementation for the Linux kernel.

The developers of LIDS have included installation instructions in the INSTALL file. However, I describe the main tasks in this article.

The stable releases of LIDS are created against a vanilla source of the Linux kernel. It is recommended that the LIDS patch be applied only to the original kernel source, not to the distribution-specific source, as it may lead to various compilation errors, as most distributions customize the kernel for their own use. LIDS is known to have problems when used on non-i386 architectures.

For example, lids-2.2.1-2.6.13.tar.gz should be applied to the 2.6.13 kernel.

After patching the kernel with:

patch -p1 /dir_to_the_patch_file/patch-lids-2.2.1-2.6.13

You can run make [x/menu]config and select the LIDS options from the security section and compile the kernel with:

make make modules_install

(if you configured any parts of the kernel as modules).

Copy the bzImage from /kernelpath/arch/i386/boot to your /boot directory, and re-initialize your bootloader. Restart into your LIDS-enhanced kernel.

You can see the status of your LIDS installation by typing:

If you get an error, LIDS was not installed into the kernel; check your kernel configurations and recompile.

Before we set access controls for various server applications, here is the general syntax of lidsconf:

lidsconf -A [-s subject] -o object [-d] [-t from-to] [-i level] -j ACTION

The subject is a program upon which a capability is added. The object can be a binary, directory, socket name or a capability.

The -d switch tells LIDS that the domain is an exec domain. The -t lets you set a specific time dependency for the capability and -i defines the inheritance level.

The -j switch is an action that can be one of the following:

DENY: denies access to the object.
READONLY: sets the object to read-only.
APPEND: mostly used for logs, this allows a certain program to append only that file, not remove it.
WRITE: allows other binaries to write on the file.
GRANT: used in conjunction with a capability, used to grant the subject a capability.
IGNORE and DISABLE: two options that allow you to disable the setting of any permission on a certain object and disable some extension features, respectively.

The capabilities LIDS supports are the following, as can be seen by typing:

CAP_CHOWN: chown/chgrp.
CAP_DAC_OVERRIDE: DAC access.
CAP_DAC_READ_SEARCH: DAC read.
CAP_FOWNER: owner ID, not equal user.
ID CAP_FSETID: effective user ID, not equal owner.
ID CAP_KILL: real/effective ID, not equal process.
ID CAP_SETGID: set*gid(2).
CAP_SETUID: set*uid(2).
CAP_SETPCAP: transfer capability.
CAP_LINUX_IMMUTABLE: immutable and append file attributes.
CAP_NET_BIND_SERVICE: binding to ports below 1024.
CAP_NET_BROADCAST: broadcasting/listening to multicast.
CAP_NET_ADMIN: interface/firewall/routing changes.
CAP_NET_RAW: raw sockets.
CAP_IPC_LOCK: locking of shared memory segments.
CAP_IPC_OWNER: IPC-ownership checks.
CAP_SYS_MODULE: insertion and removal of kernel modules.
CAP_SYS_RAWIO: ioperm(2)/iopl(2) access.
CAP_SYS_CHROOT: chroot(2).
CAP_SYS_PTRACE: ptrace(2).
CAP_SYS_PACCT: configuration of process accounting.
CAP_SYS_ADMIN: tons of admin stuff.
CAP_SYS_BOOT: reboot(2).
CAP_SYS_NICE: nice(2).
CAP_SYS_RESOURCE: sets resource limits.
CAP_SYS_TIME: sets system time.
CAP_SYS_TTY_CONFIG: tty configuration.
CAP_MKNOD: mknod operation.
CAP_LEASE: taking leases on files.
CAP_HIDDEN: hidden process.
CAP_KILL_PROTECTED: kill protected programs.
CAP_PROTECTED: protect the process from signals.

This article assumes that you have installed LIDS and its associated administration tools.

We will set up a system with tight security settings, and the services that will be allowed to run are MySQL, Apache and Bind.

The sample commands below assume that the Apache installation resides in /usr/local/apache, with a log directory of /var/log/httpd, and also assumes your Apache configuration directory is /etc/httpd. MySQL is assumed to be installed in /usr/local/mysql. Obviously, you’ll want to change the commands to suit your installation if it differs.

It is beyond the scope of this article to cover everything necessary to secure your system completely. However, these examples of how access control is administered in LIDS should get you started.

After you restart LIDS, you can begin adding access controls to various system binaries and libraries. The following sets the /sbin, /bin, /usr/bin and /lib to read-only:

lidsconf -A -o /sbin -j READONLY lidsconf -A -o /bin -j READONLY lidsconf -A -o /usr/bin -j READONLY lidsconf -A -o /lib -j READONLY

Next, we define some additional access controls for /opt, /etc and /usr/local/etc, which should be read-only, and we deny all access to /etc/shadow and the boot manager file:

lidsconf -A -o /etc -j READONLY lidsconf -A -o /usr/local/etc -j READONLY lidsconf -A -o /etc/shadow -j DENY lidsconf -A -o /etc/lilo.conf -j DENY

Because we have denied all access to /etc/shadow, the system will not be able to authenticate logins, thus we need to allow login and vlock to have read-only access to the file. Additionally, su also should have read-only access to the /etc/shadow file:

lidsconf -A -s /bin/login -o /etc/shadow -j READONLY lidsconf -A -s /usr/bin/vlock -o /etc/shadow -j READONLY lidsconf -A -s /bin/su -o /etc/shadow -j READONLY

We need to set some other access controls for su, in order for it to work with UIDs and GIDs, and access the /etc/shadow file:

lidsconf -A -s /bin/su -o CAP_SETUID -j GRANT lidsconf -A -s /bin/su -o CAP_SETGID -j GRANT lidsconf -A -s /bin/su -o /etc/shadow -j READONLY

Now, we need to allow init, login and associated applications to have write access to log files:

lidsconf -A -o /var/log -j APPEND lidsconf -A -s /bin/login -o /var/log/wtmp -j WRITE lidsconf -A -s /bin/login -o /var/log/lastlog -j WRITE lidsconf -A -s /sbin/init -o /var/log/wtmp -j WRITE lidsconf -A -s /sbin/init -o /var/log/lastlog -j WRITE lidsconf -A -s /sbin/halt -o /var/log/wtmp -j WRITE lidsconf -A -s /sbin/halt -o /var/log/lastlog -j WRITE lidsconf -A -s /etc/rc.d/rc.sysinit -o /var/log/wtmp -i 1 -j WRITE lidsconf -A -s /etc/rc.d/rc.sysinit -o /var/log/lastlog -i 1 -j WRITE

Now, we set up access control for root’s home folder. We allow only the bash history file to be appended:

f -A -o /root -j READONLY lidsconf -A -s /bin/bash -o /root/.bash_history -j APPEND

Finally, we allow the init program to kill processes on shutdown:

lidsconf -A -s /sbin/init -o CAP_INIT_KILL -j GRANT lidsconf -A -s /sbin/init -o CAP_KILL -j GRANT

Now, we allow fstab and init scripts to mount filesystems, kill processes and unmount filesystems:

lidsconf -A -s/etc/fstab -o CAP_SYS_ADMIN -j 1 -j GRANT lidsconf -A -s /etc/rc.d/init.d/halt -o CAP_INIT_KILL -i 1 -j GRANT lidsconf -A -s /etc/rc.d/init.d/halt -o CAP_KILL -i 1 -j GRANT lidsconf -A -s /etc/rc.d/init.d/halt -o CAP_NET_ADMIN -i 1 -j GRANT lidsconf -A -s /etc/rc.d/init.d/halt -o CAP_SYS_ADMIN -i 1 -j GRANT

Apache needs to have setuid and setgid capabilities. We also need to allow Apache to access log files and deny other applications from accessing the httpd binary:

lidsconf -A -s /usr/local/apache/bin/httpd -o CAP_SETUID -j GRANT lidsconf -A -s /usr/local/apache/bin/httpd -o CAP_SETGID -j GRANT lidsconf -A -o /etc/httpd -j DENY lidsconf -A -s /usr/local/apache/bin/httpd -o /etc/httpd -j READONLY lidsconf -A -o /usr/local/apache -j DENY lidsconf -A -s /usr/local/apache/bin/httpd -o /usr/local/apache -j READONLY lidsconf -A -o /var/log/httpd -j DENY lidsconf -A -s /usr/local/apache/bin/httpd -o /var/log/httpd -j APPEND lidsconf -A -s /usr/local/apache/bin/httpd -o /usr/local/apache/logs -j WRITE

For MySQL, we need to deny other applications’ access to the mysql binary. We also need to restrict access to the mysql/var directory so that it’s append=only, and allow read-only access for the mysqld dæmon to the mysql directory:

lidsconf -A -o /usr/local/mysql/var -j APPEND lidsconf -A -o /usr/local/mysql -j DENY lidsconf -A -s /usr/local/mysql/libexec/mysqld -o /usr/local/mysql -j READONLY lidsconf -A -s /usr/local/mysql/libexec/mysqld -o /usr/local/mysql/var -j WRITE

Bind needs a lot of capabilities to run:

lidsconf -A -s /usr/sbin/named -o CAP_NET_BIND_SERVICE 53 -j GRANT lidsconf -A -s /usr/sbin/named -o CAP_SETPCAP -j GRANT lidsconf -A -s /usr/sbin/named -o CAP_SYS_CHROOT -j GRANT lidsconf -A -s /usr/sbin/named -o CAP_SYS_RESOURCE -j GRANT lidsconf -A -s /usr/sbin/named -o CAP_SETUID -j GRANT lidsconf -A -s /usr/sbin/named -o CAP_SETGID -j GRANT

lidsconf -A -s /bin/login -o /etc/shadow -j READONLY lidsconf -A -s /bin/login -o CAP_SETUID -j GRANT lidsconf -A -s /bin/login -o CAP_SETGID -j GRANT lidsconf -A -s /bin/login -o CAP_CHOWN -j GRANT lidsconf -A -s /bin/login -o CAP_FSETID -j GRANT

After having specified the previous commands, we need to seal the kernel, so that the system can take full advantage of LIDS. We add this line to rc.local:

Restart the machine to apply all the new access controls. With the previously mentioned access controls, you will not be able to run the X server as it uses raw I/O, but most servers don’t run an X server anyway. If you really need it, add the following access control (this command assumes that your X server binary is located in /usr/X11R6/bin/startx):

lidsconf -A -s /usr/X11R6/bin/startx

As we can see, LIDS is a powerful addition to the Linux kernel, which can secure your system completely, even from the root user. LIDS is also very easy to use.

Irfan Habib is a software engineering student at the National University of Science and Technology in Pakistan. He has had great interest in Linux and open-source technology since high school—everything from embedded Linux development to Web services. He has been advocating GNU/Linux in Pakistan for the past two years and has written various articles in local magazines and newspapers on the subject.

Источник