On Wed, Feb 27, 2019 at 8:47 AM Peter Humphrey <pe...@prh.myzen.co.uk> wrote: > > On Wednesday, 27 February 2019 12:27:59 GMT Mick wrote: > > > > Could it be these versions are now launching /run/udev.pid? Is a file /run/ > > udev.pid present in your system? > > Yes, I have such a text file, containing just a PID. > > > In any case, the file merely contains the PID number of > > /lib/systemd/systemd- udevd, rather than an ELF binary and /etc/init.d/ > > does not contain anything suspicious. However, with armies generating > > variants of every conceivable malware I don't know if it pays to be a bit > > paranoid about this. > > They really are out to get us... >
If it really looks like a PID file I'd assume that this is a false positive. It would likely be generated by openrc and the init.d script. Since almost no other distros use OpenRC it isn't entirely surprising that a tool like rkhunter wasn't tested using it to catch the false positive. I'd report the issue to them. If by "they" you meant systemd I don't really see how they're actually involved. Well, other than indirectly by virtue of not creating this file and being the only config the rkhunter maintainers are probably using. Keep in mind that by its nature rkhunter is going to be a bit limited, at least when used in this way. If it supports offline scanning (ie from a rescue disk) then that would be pretty secure, but if it is running on a potentially-compromised kernel then a clever rootkit could evade it. Just the usual cat-and-mouse game with these sorts of things, but rkhunter can only see the filesystem and process tree that the potentially-compromised kernel lets it see. Offline scanning tools are always going to be superior in this regard, if you have known-clean (ideally read-only) boot media, and a clean firmware to boot it from. Really the cleanest solution would be to remove the hard drives and scan them on a separate machine. -- Rich
