Bug 865390 - SELinux denies getattr to perl strict.pm module
SELinux denies getattr to perl strict.pm module
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy (Show other bugs)
6.3
All Linux
unspecified Severity medium
: rc
: ---
Assigned To: Miroslav Grepl
Michal Trunecka
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-11 06:29 EDT by John Horne
Modified: 2014-09-30 19:33 EDT (History)
4 users (show)

See Also:
Fixed In Version: selinux-policy-3.7.19-172.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-21 03:31:12 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Horne 2012-10-11 06:29:54 EDT
Description of problem:
The /etc/cron.daily/freshclam script is part of the ClamAV package. It is used to update the local anti-virus databases. In /etc/freshclam.conf we have set 'OnUpdateExecute' to run a local perl script. ('OnUpdateExecute' gets run if the local databases are actually updated.) The local script uses 'strict.pm', but SELinux is denying it access to the module. The cron script emails an error message to root that 'strict.pm' cannot be found.

This problem does not exist on our RHEL 5.8 systems despite using the exact same configurations and scripts.


Version-Release number of selected component (if applicable):
selinux-policy-3.7.19-155.el6_3.4.noarch
clamav-0.97.6-1.el6.x86_64

How reproducible:
The problem occurs each time the freshclam script runs in the early morning.

Steps to Reproduce:
1. Install ClamAV, and modify /etc/freshclam.conf to use 'OnUpdateExecute' to run a perl script using strict.pm.
2.
3.
  
Actual results:
Email message sent to root:

=============================
Can't locate strict.pm in @INC (@INC
contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /usr/local/bin/xymon_event line 15.
BEGIN failed--compilation aborted at /usr/local/bin/xymon_event line 15.
=============================

Expected results:
Local script should run with no problems. No email message should be sent to root.

Additional info:

As can be seen above in the message sent to root @INC includes '/usr/share/perl5'. This is where the 'perl' package installs strict.pm:

=========================
ls -l /usr/share/perl5/strict.pm
-rw-r--r--. 1 root root 3716 Jun 22 14:28 /usr/share/perl5/strict.pm
=========================

The /var/log/audit/audit.log' shows SELinux denying access:

=========================
type=AVC msg=audit(1349922579.929:111741): avc:  denied  { getattr } for  pid=29296 comm="xymon_event" path="/usr/share/perl5/strict.pm" dev=sda1 ino=922261 scontext=system_u:system_r:freshclam_t:s0-s0:c0.c1023 tcontext=system_u:object_r:usr_t:s0 tclass=file
=========================

The in-house perl script 'xymon_event' starts with the statement 'use strict.pm;'. This script is part of our monitoring system and works fine throughout the day, and on other 6.3 and 5.8 servers. It is only this freshclam/clamav problem, on RHEL 6.3, that is occurring.

I noticed that on our RHEL 5.8 systems strict.pm is in a 'lib' directory with different attributes:

RHEL 5.8:
=========================
ls -Z /usr/lib/perl5/5.8.8/strict.pm
-rw-r--r--  root root system_u:object_r:lib_t          /usr/lib/perl5/5.8.8/strict.pm
=========================

RHEL 6.3:
=========================
ls -Z /usr/share/perl5/strict.pm
-rw-r--r--. root root system_u:object_r:usr_t:s0       /usr/share/perl5/strict.pm
=========================
Comment 3 Miroslav Grepl 2012-10-15 14:38:56 EDT
Fixed in selinux-policy-3.7.19-172.el6
Comment 6 errata-xmlrpc 2013-02-21 03:31:12 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0314.html

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