APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

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.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> Lids

1 comment

Inexpensive and informative Apple related e-books:

Take Control of Parallels Desktop 12

El Capitan: A Take Control Crash Course

Take Control of iCloud

Take Control of Numbers

Take Control of the Mac Command Line with Terminal, Second Edition

More Articles by © Tony Lawrence

Fri Apr 8 02:48:07 2005: 298   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. (link)

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.

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.


Printer Friendly Version

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

Printer Friendly Version

Computer Science is embarrassed by the computer. (Alan Perlis)

Linux posts

Troubleshooting posts

This post tagged:


Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode