Bug 225322

Summary: chkrootkit falsely flags files owned by valid packages
Product: [Fedora] Fedora Reporter: Steve Friedman <steve>
Component: chkrootkitAssignee: Michael Schwendt <bugs.michael>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 6   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-01-30 21:44:20 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Steve Friedman 2007-01-29 21:53:12 UTC
Description of problem:


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

chkrootkit-0.47-1.fc6
perl-5.8.8-10
libgcj-4.1.1-51.fc6

How reproducible:
always

Steps to Reproduce:
1. install above packages
2. run 'chkrootkit'
3.
  
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 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-1.5.0.3/.autoreg /usr/lib/firefox-1.5.0.2/.autoreg
/usr/lib/firefox-1.5.0.8/.autoreg /usr/lib/firefox-1.5.0.1/.autoreg
/usr/lib/qt-3.3/etc/settings/.qt_plugins_3.3rc.lock
/usr/lib/qt-3.3/etc/settings/.qtrc.lock /usr/lib/firefox-1.5/.autoreg
/usr/lib/perl5/5.8.8/i386-linux-thread-multi/.packlist
/usr/lib/firefox-1.5.0.4/.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
this,

Searching for OBSD rk v1... /usr/lib/security
/usr/lib/security/classpath.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,
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
check.