A.P. Lawrence

2005/04/08 Lids

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.

Comments /Words2005/2005_04_08.html


Fri Apr 8 02:48:07 2005: Subject:   drag
Good stuff.



Also for a similar thing, Fedora Core 3 and Redhat ES 4 use limited ruleset to impliment MAC thru SELinux for some convienent services. Mostly stuff that gets exposed to the network. They are trying to find a balance between keeping it usefull yet have it not get in the way of normal administration stuff.

Although I suppose most people here already knew all this. http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/

It's nice to see that other people are taking advantage of the Linux security module framework. There have been more then a few Linux security people to critize it.
http://www.grsecurity.net/lsm.php

One of the main negative aspects that is pointed out is that most Distros will be like, 'oh lsm is cool!' and impliment it by default on kernels they provide without much considuration. If a attacker could get root it can provide a ready-made and very 'secure' thing to use to deploy linux kernel module-based rootkits.

On another side note, LSM can be used for more then just security. One of the ways that you can use this framework for non-security setups is for audio workstations. It's very important sometimes to have a garrenteed latency, or in other words 'realtime', when mixing several different channels of audio in software. With 2.4 series kernels you'd have to apply patches to get this, but with 2.6 series kernel's scedualer is adequate to provide this, however you'd need to have 'root' rights to get this. So many times audio workstaitons will be run with root as the normal user. Using LSM you can set it up so that certain users have access to scedualing priority without having to grant them other rights to the rest of the system. You can find it around being called realtime-lsm.



Add your comments

Why no "Digg this!" etc.?

Need eyes on the ground at your customer's site?
Installation and light training Boston and New England
Reliable and experienced, punctual and professional.

Enter your email address for automatic notification of new posts here
(be sure to whitelist 'feedburner.com' if you use spam filtering)

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

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. We appreciate comments and article submissions.

Publishing your articles here