Thanks - i really like the idea to checking whether results are from Debian packages as that is the first thing a user will want to know. I doubt upstream would include such a patch, but debian has already made huge changes to the output.
There is no concept of 'INFO' or 'lowering' of messages in chkrootkit - you either get a output tagged 'WARNING' or you get no output. It would be more work to introduce such a concept than you might expect, and im not sure there is any value to the user. Nor is it technically correct -- a 'warning' is appropriate regardless of the source of the file: it's a sign that something unusual has been seen, rather than proof of a rootkit. And debs can come from 3rd parties not just debian -- we dont want to assume that some non-free fooo.deb from who-knows-where is definitely safe. So we should leave the output as WARNING, -- but we could change the output to indicate files from debian packages where this can be identified. I would definitely want the output to indicate if a file was modified or not, and the name of the debian package shipping it. It is probably worth applying this to other tests that identify files - so we'd need a function to filter the output: debian has already patched most tests to use a single function so this isnt as much work as it sounds (untested!). If you want to submit a patch, see the repository on salsa.debian.org and make sure to apply debian's many patches first - one way is to do a 'gbp pq import' to bring in all the debian patches, edit chkrootkit and then 'gbp pq export' The things that spring to mind are - you need to handle paths affected by usrmerge: if the debian foo packages ships /lib/foo/.file it may be flagged as /usr/lib/foo/.file but dpkg -S will not say that /usr/lib/foo/.file has not come from a package. (ie you need to search both variants through dpkg -S before concluding it is non-debian - the patch should be made this clear in any output too, somehow) - to support the '-p' option it needs to use the defined variables like $egrep and $sed - shellcheck will tell you to avoid things like ls and use globs -- you absolutely do need to quote variables in the patch to avoid word-splitting by the shell - an autopkgtest should be added: changing the output will definitely cause some tests to fail so they need updating as well you final point about checking the contents of directories is interesting idea, but i wonder if it can be done reliably. Seems like there could be all sorts of edge cases where a .directory contains a mix of files, directories and symlinks, some of which are shipped and others not (or symlink loops if we try and recurse?). It would definitely need a lot of testing. maybe best to just let those be flagged as 'non debian' -- i suspect we have no way to identify things created in maintainer scripts anyway so such a check can never be 100%. On Sun, 15 Oct 2023 at 09:39, Alban Browaeys <[email protected]> wrote: > when chkrootkit-daily runs (was with old /etc/ckrootkit.conf thus diff mode > false and "-q -n" flags) I get reports for files owned by Debian > packages and that are iso with their installation state: > WARNING: The following suspicious files and directories were found: > /usr/lib/debug/.build-id > I cooked such a script: > for file in $(grep /usr/lib /var/log/chkrootkit/log.today); do for pkg in > $(set -o pipefail; dpkg -S $file 2>/dev/null | sed 's/: .*//' | tr ',' > '\n'); do for md5pkgfile in $(ls /var/lib/dpkg/info/$pkg.md5sums 2> > /dev/null); do [ -f "$file" ] && grep ${file:1} $md5pkgfile | ( read -r > md5filepkg filepkgpath; md5file="$(md5sum "/$filepkgpath" | cut -d' ' -f1)"; > [ "x$md5filepkg" = "x$md5file" ] && echo "Debian unmodified $file" || echo > "non Debian or modified $file"); done; done ;done > gives: > Debian unmodified /usr/lib/jvm/.java-1.17.0-openjdk-amd64.jinfo > (...) > It does not handles directories like /usr/lib/debug/.build-id. Maybe > chkrootkit could check none of the files in such a dot directory are > non Debian packages installed files unmodified and owned by still > installed packages?
