LIDS is a kernel patch that implements Mandatory Access Control (MAC). Under the most restrictive circumstances, this means that not even root can do anything that lids has been configured not to allow.

You can, for example, set any file you like to read-only. While running under LIDS, that's it: the file cannot be modified or removed even by root. Doing that to a directory recursively protects everything under that directory, so that's both powerful and (of course) dangerous. You can also "hide" files or directories, and as with read-only, not even "root" can see them. Files can be set to append-only mode, which effectively prevents log-file tampering (though makes rotating log files rather more difficult). With any of these settings, you can specify programs that ARE allowed access - for example, login and sshd definitely need to read /etc/shadow.

Similar security restrictions can protect the use of ports, and even processes: a process can be hidden (still can be killed if its pid is known) or even made unkillable.

Then there's the problem of loadable modules. You almost certainly need to be able to load modules during boot, but you don't want someone circumventing all this security later. Therefore, you can "seal" the LIDS kernel in a startup script, which does just what it sounds like.

Obviously, this can make a very safe and secure system. Just as obviously, it can make for a very dead, unusable system if you screw up the configuration, so anyone new to this would be well advised to deploy it in a test system first and make darn sure that they have a non-lids kernel available to boot from if necessary. You can pass a "lids=0" parameter to a lids kernel, but of course that assumes you are allowed access to modify boot commands.

There are options that can let you make changes without rebooting. If allowed in the original compilation, you can enter a "LIDS free session"; a terminal session not subject to LIDS control. That requires another password (the LIDS password), and only one such session can exist at once. It may also be possible to turn off LIDS security with a lidsadm command, but again that capability can be compiled out.

While this is powerful stuff, it may take some fiddling to get things able to work while still providing as much protection as possible. It would be pointless to deploy LIDS and then effectively cripple it for convenience, but on the other hand there are tasks that need to have free rein, and you may not be able to identify all of them off the top of your head, so you won't know that LIDS has broken them until later.. but allowing the necessary access may accidentally open up more than you intended. However, LIDS can certainly provide a lot more protection than a normal kernel can. But that doesn't mean that you suddenly have immunity from any security problems; LIDS is just another tool that can help protect you. Nor should you neglect all the other, more "normal" security precautions you would take: protection in depth is always the wise choice. So, if (for example) a particular service is not to be used on this server, you block it at the firewall, you block it in iptables, you shut it off in xinetd, you set any available PAM restrictions that apply, AND you use LIDS to restrict its port from being used. Paranoid? You betcha.

Got something to add? Send me email.

1 comment

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us