Description of problem: No patform-version (i386, x86_64, ppc) of Fedora Core 5 (Bordeaux) is present in /var/rkhunter/db/os.dat. Not speaking about the list of known good md5sums. In other words, although a FC5 rpm exists, the distro is unsupported. This makes rkhunter complain on startup and ALWAYS report possible infection. Version-Release number of selected component (if applicable): rkhunter-1.2.8-3.fc5 How reproducible: Always Steps to Reproduce: 1. rkhunter --cronjob --disable-md5-check Actual results: Rootkit Hunter 1.2.8 is running Mon, 24 Apr 2006 20:18:33 +0200 Determining OS... Unknown Warning: This operating system is not fully supported! Warning: Cannot find md5_not_known All MD5 checks will be skipped! ... Expected results: Rootkit Hunter 1.2.8 is running Mon, 24 Apr 2006 20:40:48 +0200 Determining OS... Ready ...
Created attachment 128386 [details] OS detection patch. OS detection patch. Should fix the unknown problem.
I of course locally edited /var/rkhunter/db/os.dat to achieve the same but this asks for a new package release. I also asked rkhunter maintainer(s) for addition of FC5 support meanwhile, though this would be really better handled by FE package maintainer...
Do you have any idea how to create the md5 checksum data base?
The format seems to be simple os_identifier:md5_sum:[sha1_sum:[file_size:[package_name:]]] so it is trivial to generate (I cannot find some of these fields actually used anywhere though): for x in INTERESTING FILES; do echo 12345:$x:$(md5sum $x|cut -b-32):$(sha1sum $x|cut -b-40):$(stat -c%s $x):$(rpm -qf $x): >>HASHFILE done But I do not see much point generating the hashes when the next rkhunter --update overwrites it. It should either get upstream or it is useless. Or at least the update script would have to be fixed to merge rkhunter's database with some Fedora database -- and update that when updated packages are released for Fedora. In addition checksum verification does not seem to be something rkhunter can do better than plain rpm --verify anyway (beside being a second more or less independent source of file checksums).
AFAIR rpm --verify is very slow and cannot be limited to a selected set of files.
The main point was that if you do include the hashes for Fedora, you have to deal 1. with Fedora updates (releasing timely updates of the checksums) 2. with rkhunter --update (preventing it from overwriting it with upstream which lacks Fedora checksums) The latter reminds me of another packaging problem: rpm --verify on rkhunter itself reports these files as changed: SM5....T /var/rkhunter/db/defaulthashes.dat SM5....T /var/rkhunter/db/mirrors.dat SM5....T /var/rkhunter/db/os.dat SM5....T /var/rkhunter/db/programs_bad.dat SM5....T /var/rkhunter/db/programs_good.dat Since they are *supposed* to change with rkhunter --update, there is no point veryfying their checksums and they should be marked %verify(not md5 size mtime) in spec the %files section.
David NeÄas (yeti.cz) wrote: > It should either get upstream or it is useless. I too, am at the mercy of the package author with regards to database updates. I have hopes that FC5 support will be forthcoming at which time the *current* RPM (rkhunter-1.2.8-3.fc5) will retrieve the updated database files on the next cron run. It is unfortunate that it has taken longer than expected... When a new set of database files are available that support FC5, I will release an updated FC5 RPM (?rkhunter-1.2.8-4.fc5) with those new database files... I am more concerned about the .spec configuration error that inadvertently got into the current release of rkhunter for FE. You are correct that they are *supposed* to change and should have been tagged with the %verify directive. I hope we will see FC5 support added soon...
Well, tonight my corrected os.dat was updated to an upstream version without Fedora. So we have to deal with point 1. anyway. Here's a patch to append the contents of /var/rkhunter/db/foo.fedora to /var/rkhunter/db/foo every time /var/rkhunter/db/foo is updated.
Created attachment 128702 [details] proposed patch Amend updated db files with fedora-specific data.
Created attachment 128703 [details] proposed patch When we are at it, I also propose the attached patch. It is true on Fedora /tmp generally has +t permission and therefore mktmp(1) can work without race conditions, but I do not understand why to rely on that when we can use ${DBDIR} itself -- where the file will be finally placed -- for the temporary file too.
And it should not do mv ${TMPFILE} ${DBDIR}/${FILENAME} anyway (I forgot to include in the patch). It should do cat ${TMPFILE} >${DBDIR}/${FILENAME} to preserve the attributes of ${DBDIR}/${FILENAME}. Another problem is that the db files are not signed in any way -- although it would be easy to sign them with gpg and distribute the public key needed to verify their autenticity directly with rkhunter. Unfortunately, this cannot be fixed in Fedora unless we want to maintain our own db file mirrors. Granted, once you are 0wned you cannot trust anything so it would be hypocritical to pretend real security in a program supposed to be run in these conditions, but the shell programming quality does not strike me as extraordinarily good and I wonder what is in the 5000+ lines I have not looked at...
Well it looks like there is finally some FC5 support in the MD5 Hashes and OS files as of version 2006100500, which was updated for me last night (from 2006022800). However, with this MD5 file, 38/51 MD5 hashes failed. This *is* progress. How do we now keep the MD5 hases up-to-date?
My system just updated the MD5 hashes again last night to version 2006101202 and ALL 50 MD5SUMS PASSED! (Should I be worried that its 50/50 and not 51/51?)
rkhunter is not available in Fedora anymore[1], so this bug won't be fixed. Therefore I close it. [1] https://admin.fedoraproject.org/pkgdb/packages/name/rkhunter