I'm getting thoroughly fed up with Debian's chkrootkit program, which keeps giving me false alarms.

For a start, shortly after I installed it it began reporting that my computer had a packet sniffer installed on it, on the basis that one of my network interfaces was in promiscuous mode. It helpfully tracked down the offending binary for me, which turned out to be dhcpd. But that's supposed to put network interfaces in promiscuous mode!

A couple of months ago I installed the Debian packages of the Sun Java runtime (sun-java5-jre and sun-java5-bin) from backports.org, and chkrootkit wasn't happy with that either; it seems that those packages create a couple of files whose names begin with dots (/usr/lib/jvm/.java-1.5.0-sun.jinfo and /usr/lib/jvm/java-1.5.0-sun-1.5.0.10/.systemPrefs) and that chkrootkit objects fundamentally to the existence of any dotfiles it doesn't specifically know about. Never mind that one of those files is a symlink to a directory in /etc, and the other isn't executable. Obviously they represent a security risk.

More recently, I've been doing 15-hour fractal rendering runs overnight, in which a main process constantly spawns subprocesses to do most of the work (thus permitting some parallelism and hence taking advantage of my dual-core machine) and collates their output. The result of this is that chkrootkit insists that I have a Linux kernel module trojan installed. Why? Because when it ran ps and then scanned /proc, the two lists of processes didn't match up. Not because anything was deliberately hiding a process, but simply because processes were starting up and shutting down too quickly for it.

And today I received cron-mail telling me ‘INFECTED (PORTS: 600)’. Something was listening on port 600 on my machine, and chkrootkit apparently considers this sufficient evidence to send me mail asserting in capital letters than I am INFECTED. Only when I tracked down the offending process, it turned out to be rpc.statd, which had happened to be assigned that port number by the port mapper, and which cheerfully adopted a different random port number when I shut down and restarted it.

The last of those was particularly irritating because while all the previous reports had been phrased along the lines of ‘here is a suspicious circumstance which you might want to look into’, this one actually said ‘INFECTED’ in a tone suggesting it was in no doubt at all, which then makes it significantly less excusable when it turns out to be wrong.

But all of these messages have been pretty annoying. Most of them don't really report adequate information: the report about the two dotfiles, for example, sent me cron mail which just gave the names of the dotfiles and didn't tell me what it disliked about them at all. You'd have thought it wouldn't have been too much effort to construct a sentence, along the lines of ‘There is a suspicious dotfile at <pathname>. Suspicious dotfiles sometimes indicate the presence of a trojan. To investigate further you should <do some stuff>’. But no; I just get a message which gives the names of the files, not even with the basic decency to separate them with a line break, and no surrounding text at all. And most of the other reports were similarly terse to the point of incomprehensibility: in most cases I had to go grubbing through the chkrootkit source to find out what it was even talking about, let alone work out what I should do about it. I'm lucky I have the skills to do that; I have Debian-using friends who would be in a constant state of worry if they kept receiving communications like this. (As opposed, that is, to my own state of barely controlled outrage.)

Also, the rate of false positives is somewhat excessive. At this rate, if someone ever does install a rootkit on this machine, I'll probably assume it's just chkrootkit crying wolf yet again.

And the fact that Debian packages trigger these problems is also particularly unhelpful. One is tempted to suggest that there should be a systemwide file of exemptions in which any package that did something potentially objectionable could register itself, and thus dhcpd and chkrootkit would be able to coexist on the same system without the latter being in a permanent strop at the former. Presumably the counter-argument to that is that then a real rootkit could make use of the same mechanism to prevent chkrootkit reporting its activities, and I suppose that's a fair point; but on the other hand, these false positives are a security problem too and it's not immediately clear to me that the current is better than the one I describe here. Also, it's not as if a rootkit couldn't do at least as good a job of concealment by nobbling the chkrootkit script itself or the cron script that runs it overnight. If, that is, a chkrootkit-aware rootkit didn't simply avoid doing any of the specific things that would trigger a complaint.

(In fact, I nobbled the cron script myself to deal with the dhcpd problem, by having it grep out those particular lines from chkrootkit's report. It was that or receive an email every night for the lifetime of this system helpfully reminding me that it has a DHCP server installed.)

Failing that, you'd think that at least Debian packages could be tested against chkrootkit, and avoid doing things they knew would worry it. For example, either chkrootkit should not assume anything listening on port 600 is necessarily hostile, or rpc.portmap should avoid assigning legitimate system services to port 600. I don't care which, but one of them. (Though admittedly this strategy probably doesn't work so well for dhcpd.)

On one of the occasions described above I mentioned it to the nearest friend of mine, who was bjh21. I asked if he knew anything about chkrootkit, and he said not really but he ‘got the impression that it worked pretty well’. I can therefore only assume that in order for Ben to have got this impression, somewhere out there there must be at least some people who run chkrootkit without it doing this to them on a regular basis. I wonder who. And how.

And finally, it's difficult to report any of this as a Debian bug, because it's fundamentally about cooperation between two packages, so I'm uncertain of which package I should report any particular incident against. Given the sheer number of the wretched things, though, perhaps I should be leaning towards the idea that chkrootkit is fundamentally the cause of the trouble and report all bugs against that unless proven to be someone else's fault.