Re: Is LIDS a good idea?
On Sam, Dez 01, 2001 at 03:32:51 +1000, mdevin@ozemail.com.au wrote:
> Sounds as though I may need a little more knowledge than I currently
> have. But on the other hand, if I do go down this path of installing
> and configuring LIDS and manage to get it to work then I will have
> learnt LOTS about all the daemons that I run on this box.
yes. but the alerting will help you. if the daemon need something which
is not allowed by the kernel, an alert will be generated. this looks
like this:
Nov 26 20:03:07 \
date time
tucan kernel: LIDS: mount ( 8 1 inode 1163318) pid 20114 \
host kernel process dev inode nr PID #
user (0/0) \
user/group (root here)
on NULL tty: \
which TTY
CAP_SYS_ADMIN violation: Try to mount /dev/sda1 on /
capability what it tried to do
> Is it easy to get rid of it, if it causes me more trouble than it is
> worth?
run an unpatched kernel, disable it with kernel option "security=0"
(e.g. lilo boot option) or disable it on runtime with
"lidsadm -S -- -LIDS_GLOBAL" (replace - by + to reactivate it)
> What I mean is: If I have trouble and decide that I don't want
> LIDS anymore, can I boot into single user mode with LIDS deactivated and
> then reinstall a previous kernel without LIDS?
sure you can. replace the kernel and /etc/lids and the whole thing's
gone.
> For example: If I make a boot floppy with a kernel without LIDS, can I
> just boot from this and everything will run as it was before I
> installed LIDS?
yes, it will. no daemon or anything else on the storage media get
changed. the only thing on the storage is /etc/lids with default
capabilities (lids.cap), LIDS password (lids.pw), remote alert
configuration (lids.net) and the LIDS configuration file (lids.conf).
> Or, will some of the changes that LIDS does to the filesystems or
> files render them unreadable by other non-LIDS kernels?
no. the ACLs are handled fully by the kernel. they are loaded at sealing
time. the ACL extensions in ext2 are not used (there are patches for
activating them, interface like solaris). LIDS works on the VFS layer
which mean, it should work on every filesystem VFS can handle (i guess
as long they provide an usable inode nr.)
>
> Thanks for all the information. Much of what you said has inspired me
> to give it a go. I was just going to go with Tripwire / AIDE but LIDS
> seems to add quite a lot of functionality.
it could be too much security (if this ever could happen). not because
you get too much security, but because it's somewhat time expensive to
configure it and could not be worth it (when you can spend time on other
hardening stuff) , but you learn a lot about your root daemons.
> ps. In terms of overall security, I do have a fairly decent iptables
> firewall - with currently no ports open to the outside. I haven't even
> allowed SSH yet - but I will (on a non standard port). It seems to me
> that the next steps for me to take for my security are to install LIDS
> and libsafe.
LIDS is good for a true multiuser system, where root is the single point
of attack and people have basic access. a true network OS (i mean e.g.
for a router) probably doesn't need this security cause it can run
independently from the other [users] and the main security stuff (e.g.
paket filtering) is already handled by other means (directly by the
kernel) and not that of a normal user concept. this good, this is evil.
Reply to: