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:
lidsadm -V
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:
lidsadm -h|grep CAP
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.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Designing Electronics with Linux | May 22, 2013 |
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
- I once had a better way I
1 hour 16 min ago - Not only you I too assumed
1 hour 33 min ago - another very interesting
3 hours 26 min ago - Reply to comment | Linux Journal
5 hours 20 min ago - Reply to comment | Linux Journal
12 hours 14 min ago - Reply to comment | Linux Journal
12 hours 30 min ago - Favorite (and easily brute-forced) pw's
14 hours 21 min ago - Have you tried Boxen? It's a
20 hours 13 min ago - seo services in india
1 day 44 min ago - For KDE install kio-mtp
1 day 45 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi

It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Featured Jobs
| Linux Systems Administrator | Houston and Austin, Texas | Host Gator |
| Senior Perl Developer | Austin, Texas | Host Gator |
| Technical Support Rep | Houston and Austin, Texas | Host Gator |
| UX Designer | Austin, Texas | Host Gator |
| Web & UI Developer (JavaScript & j Query) | Austin, Texas | Host Gator |
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?




Comments
Access controls for Jboss server.
Hi Irfan,
Your post had been very useful. Thanks first.
I was given the task of binding port 443 to JBoss server.
i have granted the NET_BIND capability on 443 port to Jboss/bin/run.sh subject. But the problem persists with exception as Permission denied :443
Can u pls help wid this.
More Information on LIDS please
Hello Irfan.
I liked your article on LIDS, but am a bit confused by the phrase:
"It is recommended that the LIDS patch be applied only to the original kernel source, not to the distribution-specific source".
I use Suse Linux 10. Does your statement mean I must somehow 'retrofit' a vanilla kernel into my distribution? This would be something well beyond my capabilities and I presume Novell wouldn't like it much either.
Where can I find LIDS?