Re: More detailed auditing design proposal
Peter Eckersley <pde@cs.mu.oz.au> wrote:
> I've started implementing a few bits and pieces of it, but I'd
> appreciate comments and constructive criticism before I do too much.
The basic goal looks nice (especially the Debian-specific part), however
on the implementation side... the need to reboot to perform verification
is really undesirable. Let me put it this way: the systems that I am
most eager to keep secure are the ones I can least afford to shut down,
not to mention doing so on a, say, weekly basis.
I understand that the problem being you cannot trust any part of the
original system because they may also be compromised. But... have you
considered using LIDS (www.lids.org) to solve this problem? LIDS is
a kernel patch and a user space utility that enforces more fine-tuned
system access policy (through the kernel capability support) and file
protection schemes, with remote email warning capabilities built into
the kernel.
The idea is a little bit different: in kernel protection helps with the
integrity of the system, and instead of realizing that something is
wrong when you perform the next audit, you can almost catch the bad guys
in the act -- most crackers, script kiddies in particular, would most
definitely install root kits given the chance, which usually involves
touching the files is /usr (which you have set to read only). Before
the bad guy figures out why the root kit installation failed, security
alerts (in terms of policy violations) would have already been sent to
another box, so you know someone misbehaved. It can also be used to
protect tripwire databases, etc. I have carefully inspected the patch
just two months ago, which is actually quite clean. But beware that it
is not of production quality yet, especially on SMP systems (I found
and fixed two races during the audit, but there has to be more).
-- Chuan-kai Lin
Reply to: