Am 20.11.19 um 12:29 schrieb Elmar Stellnberger:
debcheckroot is targeted at technically experienced users. No way to hunt rootkits authored by the NSA otherwise. You have to be a tough user to take this challenge! Well you can of course also use it for other kinds of rootkits by other governments or from criminals but interpreting the results requires some kind of knowledge about a Linux system. You need to know what the kernel is, what an initrd is, what you can find under /bin, /usr/bin, /sbin and /usr/sbin.Why not simply use sha256 - lists as can already be used and generated with debcheckroot (as far as I have seen)? That would resolve the problem of a possible infection of the host system running debcheckroot because there are no archives that need to be unpacked when using plain sha256 file lists. We would only need some official support by Debian for this, i.e. someone who creates/updates these sha256 lists every time the updates repository is updated and puts them online in a publicly known place.
The tool has primarily been written against 5 eyes rootkits but I think it is still missing some features to take this challenge. f.i. it should be possible to unpack *.deb-s in an own boot run, separate from downloading and verification. That would shield against attacks targeted at the unpacking which affect the very system debcheckroot runs on. Supporting file only repos for customly downloaded and installed packages like my printer driver would also be an issue.
Yes, that is a very good idea!:
* debcheckroot with sha256-lists is considerably faster because it does not need to download and unpack all packages
* unknown/forgotten packages of elder versions could still be checked because the sha256sums are not forgotten
* You can generate sha256sums incrementally with debcheckroot,
i.e. extend an existing list only for the new packages