[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Root Kit Protection



On Wed, Feb 16, 2000 at 04:27:52PM -0800, Brent Fulgham wrote:
> All of this DOS stuff lately has gotten me thinking about security, and
> in particular "root kits".
> 
> I was wondering if it might make sense to have a system daemon that checked
> the versions of programs on the system against a "trusted" version table.
> Perhaps this could be something that was built into the "Packages" file
> as an additional data point (MD5 Sum: blah blah blah).
> 
> Then a cron job could run weekly/daily/hourly that checked the MD5 sum of
> /bin/sh against the one in the Packages file, libc6, etc.  Perhaps Packages
> could
> be "signed" to avoid tampering.
> 
> Does this sound like it might be useful at all?  It's roughly the same as
> tripwire or its ilk, but the auditing would be "pre-processed" such that you
> don't have to build the "before" database on your system -- it get's updated
> each time you install/upgrade Debian.

sounds like tripwire but i would hope a Free software version, which
last time i looked did not exist...

this would really be a great tool, if it were to play well with the
dpkg system, things like tripwire become rather useless or impractical
if you are following the unstable tree of debian since files on the
system change nearly every day...

for the md5 databases they would certainly have to be
cryptographically signed (GnuPG should be fine) and the utility used
to do the verification should probably be statically linked and
immutable, since if someone gets in and is aware of this system they
could replace the auditor with a fake that would never do anything but
return `hunky dory' status..  does linux have a kernel securelevel
like the BSD's? so the immutable bit can be set but not removed
without changing securelevels?  (i am only marginally familier with
BSD secure levels, so correct me if they are pointless in this
regard..) 

This is really a great idea IMO and should be explored further.

-- 
Ethan Benson


Reply to: