LIDS (Linux Intrusion Detection System)

category: howtoz/archive · date: 2007-09-12 · author: LALA

The Slovak original of this document: LIDS (Linux Intrusion Detection System) (slovensky).

noteA historical article published on 12 September 2007. It describes LIDS 2.2.x for Linux 2.6 and captures the state of Linux security at that time. The commands and procedures therefore cannot be taken as a guide for current distributions.

LIDS (Linux Intrusion Detection System) was a security patch for the Linux kernel that extended the protection of the system beyond traditional Unix permissions. It made it possible to protect files, directories and processes even from the root user, to define ACL rules, to restrict capabilities and to generate security alerts.

Architecture

LIDS 2.2.x was used as a patch for the vanilla Linux 2.6 kernel together with the lidstools package. The basic administration tools were:

bash

$ lidsadm
$ lidsconf

lidsadm was used to switch the protection on and off, check the status, reload the configuration and "seal" the kernel. lidsconf managed the ACL rules, the global capabilities and the LIDS password.

ACL and capabilities

The rules distinguished the subject (the running program) from the object it accessed. The supported actions included:

output 6 lines

DENY
READONLY
APPEND
WRITE
GRANT
IGNORE

This made it possible, for example, to set a configuration file read-only, to allow only append operations on logs, or to grant a selected capability to a particular process.

LIDS Free Session

LIDS made it possible to create an administration session without the usual LIDS restrictions. It was used when maintaining the rules or the protected files.

Sealing the kernel

Once booting had finished, it was possible to activate the global capability restrictions and further limit what the root user could do, for example to forbid adding kernel modules or access to selected system operations.

Practical problems

Strong protection also had operational consequences. Protecting /etc could collide with writing to /etc/mtab, and append-only protection of the logs complicated logrotate. When tuning, it was therefore necessary to watch the kernel messages and gradually allow only the operations that were strictly needed.

Historical significance

LIDS comes from a period when the protection of a Linux system was handled by separate kernel patches. The article captures principles that are still relevant: capabilities, protecting critical files, separating administration from normal operation, and the principle of least privilege.

Original article

2007 - LIDS (Linux Intrusion Detection System)

Current practice (checked 2026-10)

noteThe article above is kept as it was written in 2007. This section lists what has changed since and what to do instead today.

Mandatory access control: LIDS was a separate kernel patch with its own tools. Today the same job (confining programs, protecting files even from root) is done by the security modules that are part of the mainline kernel: SELinux, AppArmor, Smack, TOMOYO and Landlock. Use the one your distribution ships and supports; cat /sys/kernel/security/lsm shows which are active.
Sealing the kernel: the equivalent of forbidding module loading after boot is the sysctl kernel.modules_disabled=1, which cannot be switched back without a reboot. Kernel lockdown (Linux 5.4 and later) goes further and blocks /dev/mem, unsigned modules and other ways of modifying the running kernel.
Capabilities per program: what lidsconf did with capability grants is now done per service in its systemd unit, with directives such as CapabilityBoundingSet=, ReadOnlyPaths= and ProtectKernelModules=.
/etc/mtab: the collision between a protected /etc and writes to /etc/mtab is gone; on current distributions /etc/mtab is a symbolic link to /proc/self/mounts and nothing writes to it.

Sources: