Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 225322 - chkrootkit falsely flags files owned by valid packages
chkrootkit falsely flags files owned by valid packages
Product: Fedora
Classification: Fedora
Component: chkrootkit (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Michael Schwendt
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-01-29 16:53 EST by Steve Friedman
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-01-30 16:44:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Steve Friedman 2007-01-29 16:53:12 EST
Description of problem:

Version-Release number of selected component (if applicable):


How reproducible:

Steps to Reproduce:
1. install above packages
2. run 'chkrootkit'
Actual results:

/usr/lib/perl5/5.8.8/i386-linux-thead-multi/.packlist flagged as suspicious
/usr/lib/security/classpath.security flagged as suspicious

Expected results:

These two files are valid and warnings should not be generated on their presence.

Additional info:
Comment 1 Michael Schwendt 2007-01-29 17:25:45 EST
> /usr/lib/perl5/5.8.8/i386-linux-thead-multi/.packlist

It is in the nature of chkrootkit's check for suspicious files and
dirs that such files are reported. With different packages installed,
you can get output like:

/usr/lib/firefox- /usr/lib/firefox-
/usr/lib/firefox- /usr/lib/firefox-
/usr/lib/qt-3.3/etc/settings/.qtrc.lock /usr/lib/firefox-1.5/.autoreg

These are valid files, too, but chkrootkit cannot know that.
Maintaining a white-list is beyond the scope of packaging.
Making chkrootkit aware of RPM is a feature that should be
request upstream.


> /usr/lib/security/classpath.security flagged as suspicious

I get different results. Here it is marked as a false positive like

Searching for OBSD rk v1... /usr/lib/security

where the check seems to inaccurate.
Comment 2 Steve Friedman 2007-01-29 18:12:59 EST
I agree with what you've written.  Do you want to open it upstream, or shall I?
Comment 3 Michael Schwendt 2007-01-30 16:43:45 EST
I've mailed upstream and have added a small README to the package
doc files, which covers these issues.

The "false positives" (suspicious files) are covered by the FAQ,
too: http://www.chkrootkit.org/faq/#8

Using "rpm" to check the validity of suspicious files would create
an additional dependency on an external tool. Simply filtering out
the libgcj files from the check would result in the same answer
than in FAQ #8, so in general, not a good idea without an accurate

Note You need to log in before you can comment on or make changes to this bug.