On Thu, Dec 26, 2002 at 01:42:16PM +0000, Steve Kemp wrote: > On Thu, Dec 26, 2002 at 10:30:38AM +0100, Javier Fern?ndez-Sanguino Pe?a wrote: > > > 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 believe we are starting to have (in the distribution) too many "simple standalone tests" (I am also to blame here) > > > 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. (..) > > 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. There are some things that won't work or are not appropiate (password check: done by 'john' already , rpm check). Aside for that I guess it can be useful. I have, as a matter of fact, included some of the tests to Tiger (some were already there). Check out, for example, check_neverlogin: http://savannah.nongnu.org/cgi-bin/viewcvs/tiger/tiger/systems/Linux/2/check_neverlogin > > > 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. Yes. Tiger does that too. In 'check_passwd' alongside with a few other checks: http://savannah.nongnu.org/cgi-bin/viewcvs/tiger/tiger/scripts/check_passwd > > 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.. An automatic rollback is maybe too much. The administrator should be sent a note asking him to take proper action. > > > - 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. You mistook me. The MD5sums is for _installed_ files, not for package installation, that's a different issue (and a beaten horse). As for attacks to system integrity these are all well known. Even if an attack is possible (which might not be if you store in RO media, or use proper capabilities access to prevent even root from tampering them) it is still good to have a local database. Tiger checks the database the same way debsums does, the problem here is that MD5sums are not mandatory for packages (and dpkg does not generate them even if there are some quick hacks to do this). In order to properly check integrity it might be useful to have MD5/SHA1 sums _and_ filesystem permissions. It's not only useful to recover from a security incident, it's also useful to recover from unknowledgeable admin users (try a chmod -R 000 /usr and see if you can -easily- recover the system) > > > - 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 ;) Try to remove your libc and see your system explode :) Keeping a copy in a backup storage are of critical system files is IMHO a good thing. Automatic restoration needs to be handled carefully, but still, it's a worthwhile goal. > > - secure (of course :) Maybe it could run as a daemon instead of depending > > on cron. > > Any particular reason for this? Cron is a single point of failure for Tiger (as is the MTA). Kill cron and you've finished with all security checks. Since cron does not necesarily say anything unless there is a problem, an admin might be blissfully think all is working fine :) > > > - 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. Not really. System integrity is one thing, system security monitoring is another (different) one. Both have overlapped areas but logcheck (which does a great job BTW) does not fit into what I was thinking of. > > > 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. Don't worry about that, I'm not going to tackle that ATM either. It would be nice, however, if, in order to determine what should Debian provide as a 'standard security check' you could compare Tiger checks against SuSE's checksecurity and against OpenBSD's (I believe the last to, do the same stuff) and against RedHat's (I believe they have one but have not seen the sources of it). (Any other's?) Maybe we first need a proposal on which security checks should be done in a basic the system per default. Tiger does probably too many of them, even if a subset could be shipped in a separate package I'm not sure others would want it to be "Section: admin/Priority: standard". Regards Javi
Attachment:
pgp_wZr5rSkZT.pgp
Description: PGP signature