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

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:
 http://www.steve.org.uk/apt/ ]

> 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
           be added.

	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 [1])

  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
 for ;)

> - lightweight (to avoid system overload). See Bug #31902

  True

> - 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 [5], but that is a personal bias, after all I am the
> maintainer) 

   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.

Steve
---



Reply to: