Re: Common (basic) security checks for a base installation? (was Re: Security notification script in Perl)
On Thu, Dec 26, 2002 at 10:30:38AM +0100, Javier Fern?ndez-Sanguino Pe?a wrote:
> > There will be a Debian package available shortly, in addition
> > to the source. Requirements are minimal, libcompress-zlib-perl,
> > and libwww-perl - and it worked well enough to spot the updated
> > fetchmail packages a few minutes ago.
[Debian package is now available, and will install a daily cronjob:
> Not that I don't like people doing new stuff but why not add this to
> proper packages instead of doing new ones?
I did actually think of this myself, however I decided not to because:
1. It wasn't immediately obvious to which package it should
2. It's a very simple standalone test which requires a 'net
connection. It's roughly analagous to the `cron-apt` package.
> I have been thinking for some time that we do lack in Debian a "good
> enough" local security testing script that can "protect" the system by
> doing some basic checks.
> The checksecurity script in the cron package is a good start, but is
> clearly not sufficient (and the name is also misleading, see Bug #163813).
Looking at the bug I see no reason why we couldn't replace our package
with the SuSe one, it does the same job with more checks, and it does
appear to be GPL'd.
> I would like a base system to be able to:
> - do consistency checks for local (critical) configuration files
Thats a good idea; the SuSe checksecuriy package appears to do this
for /etc/passwd, and a few other files.
I wonder what could be done in the case of error here though, roll back
the files from /var/backup/etc/? If the machine is broken enough that
a check fails mailing root might not be the best thing to do - the root
login might be gone, or be owned..
> - do MD5sums checks for installed packages (a.k.a. as debsums, IMHO we
> _must_ provide MD5sums for all sums, even if we do have integrity checking
> tools )
Signing packages and releases is a whole other issue. It's not a great
idea to verify sums of packages against a local database, as it would be
trivial to replace the local database.
> - be able to automatically recover from some critical issues, such as
> 'base' files being removed from /lib, /usr/lib, /bin... which would turn
> the system unusable.
I thought that was what staticly linked binarys and shell built-ins were
> - lightweight (to avoid system overload). See Bug #31902
> - secure (of course :) Maybe it could run as a daemon instead of depending
> on cron.
Any particular reason for this?
> - meaningful (opposite of obscure) That is, anyone should be able to
> understand the output and take appropiate measure. This means that all
> necesary actions should be documented thoroughly.
That should be a given too. That's why my package uses the long version
of the RDF feed - so that the notifications get a paragraph of text explaining
the problem, not just the title of the advisory.
> - based on already available, and GPLd, security checks (I would like the
> base to be Tiger , but that is a personal bias, after all I am the
There are also related packages such as logcheck which could be useful.
> Are there people that could contribute time and effort in this issue?
> (like patching dpkg to fix the current related bugs or writing the
> appropiate checks to include in the cron package).
I'd be happy to spend time on this, and do the necessary work upon
checksecurity - but I'm not going to touch the package signing/fingerprinting
because I don't see how it could be done reliably.