[Techtalk] Re: LIDS and CAPSET woes

[Raven Alder]

Heya --

Quoth Mandi (Tue, Jan 07, 2003 at 10:57:23PM -0500):
> Sweet!  I'm glad you got it working.  Now you can give us the low down on 
> LIDS, right?  someone asked the linuxsecurity.com mailing list about it 
> last week i think, but the discussion i was hoping for never came.  right 
> now i don't have a machine that my users wouldn't get cranky about me 
> locking down, so i've been reluctant to hijack anything with it. 

	Sure thing -- here's my two cents about it, feel free to
comment, agree, disagree, discuss, etc.  It seems to be a good tool to
prevent folks from taking a local account and getting root on the box
and backdooring it with that access.  It can lock certain files to
read-only (much like the immutable flag), prevent key system directories
from being written to, prevent programs from binding to ports or
exercising certain OS options.  The syntax of its config program is
pretty easy to pick up if you've ever done ipchains or iptables -- I was
able to look at the man page for lidsconf once and then pretty much
create the rules I needed on the fly without continually needing to
refer to the documentation.

	Their documentation is definitely less than complete, though.
The FAQ on their website is helpful, and they have a "please help us
write documentation" plea up (once I get my config finalized I'm going
to send them a "here's a sample ruleset for this setup").  But it's not
terribly newbie-friendly -- you have to know exactly what the various
programs on your system are going to need from the OS in order to make
it work.  With strace and checking the syslog and error messages on the
screen I was able to figure it out for most of the things on my system
-- vsftpd was the only one that stumped me.  

	Like any intrusion detection system, it's probably going to take
you a while to tune it to the needs of your particular setup.  This
means that there probably will be downtime (unlike a non-reactive NIDS,
which will just spam the hell out of you with false positives, this will
actually prevent you from doing things) and tweaking required, so I
wouldn't want to roll this out on a mission-critical live server in a
five minute config window.  [grin]  Ideally, it should be the last thing
you set up on a box (and test!) before that box goes into production.

	The default config prevents you from doing a lot of common
sysadminny tasks, so you generally have to establish a LIDS-free session
to do that.  As root, you type

lidsadm -S -- -LIDS

in an xterm of your choice, and then LIDS's restrictions are turned off
for that one xterm/vty/console/what have you until either you log out of
it or you re-enable it with 

lidsadm -S -- +LIDS

If you want the system to be completely locked down so that you can't do
that without booting into a non-LIDS kernel, you can disable the ability
to establish a LIDS-free session when you configure the LIDS-patched
kernel.  I prefer ease of administration of this box to the extra level
of security (I'm only mostly paranoid, not completely so) for this box,
so I left it in there.

	I was very glad I did -- I had just finished setting up LIDS
when I read the advisories about the remote root exploit in dhcpcd,
which this machine was using.  [grin]  So I had to upgrade that.  If I
hadn't left the ability to have a LIDS-free session on, I would have
been very vexed indeed.

	It's certainly not the be-all and end-all of security solutions;
no one program is, no matter what the marketing department says.  [grin]
But I've been reasonably happy with it so far for its intended purpose.
Logging does not seem to be too verbose to be bearable, all of my
programs are working properly again (as far as I know) after about four
hours of tweaking, and I feel better about leaving the box on a network
that I don't trust very much.  

Cheers,
Raven

"Mug the Traveller."
  -- advice from the box of an Irish tea cup