On Fri, Sep 15, 2000 at 11:36:12PM -0800, Ethan Benson (erbenson@alaska.net) wrote: > On Fri, Sep 15, 2000 at 11:55:23PM -0700, kmself@ix.netcom.com wrote: > > Also, as this started off as a Debian thread somewhere/somehow, do you > > have any suggestions for auditing a box through dpkg / apt, including > > verification of packages (including checksum or signature tests where > > possible), detecting binaries *not* associated with packages, and/or > > possibly reinstalling a package over an existing instance? I believe > > RPM has at least some of these capabilities, not sure that DEBs do. > > look at the packages, debsums and cruft, debsums can check md5sums on > all files (if the package came with such a list, and not all do) cruft > alegedly finds files unexplained by the packaging system, i have not > quite figured out how to make cruft work though, it always starts > spewing off every file and directory starting from / ...and supposing debsums turns up some incorrectly checksummed packages? How do you go about correcting this? ...or do I remember reading about a reinstall w/ force option somewher.... > the problem with debsums is its trivial for a root to tamper with > /var/lib/dpkg/info/foo.md5sums. a root can also just install a custom > .deb, though this will be rather apparent the way dselect/apt > operate. (apt will always replace a custom package with the real one > if the versions are the same, dselect shows packages not listed in the > Packages.gz file as `obsolete') > > ideally what is needed is some tripwire like functionality integrated > into dpkg. tripwire is impossibly inconvenient if you install > packages often or track unstable. Oi, this would be cool.
Attachment:
pgpo66I51Cj6R.pgp
Description: PGP signature