Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 225322 - chkrootkit falsely flags files owned by valid packages
Summary: chkrootkit falsely flags files owned by valid packages
Alias: None
Product: Fedora
Classification: Fedora
Component: chkrootkit
Version: 6
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Michael Schwendt
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-01-29 21:53 UTC by Steve Friedman
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-01-30 21:44:20 UTC

Attachments (Terms of Use)

Description Steve Friedman 2007-01-29 21:53:12 UTC
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/ 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 22:25:45 UTC
> /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/ 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 23:12:59 UTC
I agree with what you've written.  Do you want to open it upstream, or shall I?

Comment 3 Michael Schwendt 2007-01-30 21:43:45 UTC
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,

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.