Bug 849671 - SELinux doesn't allow /etc/init.d/clamd.amavisd to write PID file
Summary: SELinux doesn't allow /etc/init.d/clamd.amavisd to write PID file
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy
Version: 6.3
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Miroslav Grepl
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks: 782183
TreeView+ depends on / blocked
 
Reported: 2012-08-20 14:07 UTC by Robert Scheck
Modified: 2018-11-30 21:32 UTC (History)
4 users (show)

Fixed In Version: selinux-policy-3.7.19-160.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-21 08:27:54 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 837138 1 None None None 2021-01-20 06:05:38 UTC
Red Hat Product Errata RHBA-2013:0314 0 normal SHIPPED_LIVE selinux-policy bug fix and enhancement update 2013-02-20 20:35:01 UTC

Internal Links: 837138

Description Robert Scheck 2012-08-20 14:07:40 UTC
Description of problem:
SELinux doesn't allow /etc/init.d/clamd.amavisd to write PID into the file
/var/run/amavisd/clamd.pid. This results in an AVC denied simply:

type=AVC msg=audit(1345470879.621:762244): avc:  denied  { write } for  pid=5193 comm="clamd" name="clamd.pid" dev=vda1 ino=132411 scontext=unconfined_u:system_r:clamd_t:s0 tcontext=unconfined_u:object_r:amavis_var_run_t:s0 tclass=file
type=SYSCALL msg=audit(1345470879.621:762244): arch=c000003e syscall=2 success=no exit=-13 a0=13592a0 a1=241 a2=1b6 a3=0 items=0 ppid=5192 pid=5193 auid=0 uid=497 gid=497 euid=497 suid=497 fsuid=497 egid=497 sgid=497 fsgid=497 tty=(none) ses=7525 comm="clamd" exe="/usr/sbin/clamd" subj=unconfined_u:system_r:clamd_t:s0 key=(null)
type=AVC msg=audit(1345470992.363:762250): avc:  denied  { write } for  pid=5335 comm="clamd" name="clamd.pid" dev=vda1 ino=132411 scontext=unconfined_u:system_r:clamd_t:s0 tcontext=unconfined_u:object_r:amavis_var_run_t:s0 tclass=file
type=SYSCALL msg=audit(1345470992.363:762250): arch=c000003e syscall=2 success=yes exit=5 a0=1eec2a0 a1=241 a2=1b6 a3=0 items=0 ppid=5334 pid=5335 auid=0 uid=497 gid=497 euid=497 suid=497 fsuid=497 egid=497 sgid=497 fsgid=497 tty=(none) ses=7525 comm="clamd" exe="/usr/sbin/clamd" subj=unconfined_u:system_r:clamd_t:s0 key=(null)
type=AVC msg=audit(1345471059.628:762251): avc:  denied  { unlink } for  pid=5335 comm="clamd" name="clamd.pid" dev=vda1 ino=132411 scontext=unconfined_u:system_r:clamd_t:s0 tcontext=unconfined_u:object_r:amavis_var_run_t:s0 tclass=file
type=SYSCALL msg=audit(1345471059.628:762251): arch=c000003e syscall=87 success=yes exit=0 a0=1eec2a0 a1=419f40 a2=2 a3=fffffffffffff685 items=0 ppid=1 pid=5335 auid=0 uid=497 gid=497 euid=497 suid=497 fsuid=497 egid=497 sgid=497 fsgid=497 tty=(none) ses=7525 comm="clamd" exe="/usr/sbin/clamd" subj=unconfined_u:system_r:clamd_t:s0 key=(null)

If SELinux is enforced, /var/run/amavisd/clamd.pid is simply empty, thus any
attempt to restart clamd.amavisd simply fails (stopping fails because of empty
PID and starting fails because of socket is already/still used).

Version-Release number of selected component (if applicable):
amavisd-new-2.8.0-0.el6.noarch
clamav-0.97.5-1.el6.x86_64
selinux-policy-3.7.19-156.el6.noarch
selinux-policy-targeted-3.7.19-156.el6.noarch

The amavisd-new package is right now simply a backport from Fedora Rawhide,
but I definately will push this update to regular Fedora EPEL very soon. From
my point of view this issue is also not related to my amavisd-new update, but
a general issue with amavisd-new and clamav with the SELinux policy.

How reproducible:
Everytime, see above.

Actual results:
SELinux doesn't allow /etc/init.d/clamd.amavisd to write PID file

Expected results:
SELinux allows /etc/init.d/clamd.amavisd to write PID file

Comment 2 Milos Malik 2012-08-20 15:16:42 UTC
# matchpathcon /var/run/amavisd/clamd.pid
/var/run/amavisd/clamd.pid	system_u:object_r:clamd_var_run_t:s0
#

What does "restorecon -v /var/run/amavisd" on your machine?

Comment 3 Robert Scheck 2012-08-20 15:35:39 UTC
$ matchpathcon /var/run/amavisd/clamd.pid
/var/run/amavisd/clamd.pid	system_u:object_r:clamd_var_run_t:s0
$

$ restorecon -v /var/run/amavisd
$

Comment 4 Robert Scheck 2012-08-20 15:38:58 UTC
Please keep in mind that /etc/init.d/clamd.amavisd calls the wrapper script
/etc/init.d/clamd.amavisd which finally starts the clamd process.

Comment 5 Robert Scheck 2012-08-20 15:39:25 UTC
*gna* the wrapper script is of course /usr/share/clamav/clamd-wrapper

Comment 6 Miroslav Grepl 2012-08-21 07:44:37 UTC
We have some fixes in Fedora for this issue.

Comment 7 Robert Scheck 2012-08-21 17:17:51 UTC
Yes, but this is unfortunately RHEL. When will these fixes be merged into RHEL 
selinux-policy? Will these get part (at latest) of RHEL 6.4 GA?

Comment 8 Miroslav Grepl 2012-08-24 14:03:59 UTC
It will be part of a new RHEL6.4 build which will be available on http://people.redhat.com/dwalsh/ (as usual) next week.

Comment 10 William Lovaton 2012-09-18 16:08:17 UTC
Great, let's hope it gets fixed in the next update of RHEL.  In the meantime I just loaded this policy and it seems to be working fine:

[nalwalovaton@CDPLIN80 ~]$ cat amavis-mypol.te 

module amavis-mypol 1.0;

require {
	type amavis_var_run_t;
	type clamd_t;
	class dir { write remove_name search add_name };
	class file { write unlink };
}

#============= clamd_t ==============
#!!!! The source type 'clamd_t' can write to a 'dir' of the following types:
# var_run_t, var_log_t, clamd_var_log_t, clamd_var_lib_t, clamd_var_run_t, clamd_tmp_t, amavis_spool_t, tmp_t, root_t

allow clamd_t amavis_var_run_t:dir { write remove_name search add_name };
allow clamd_t amavis_var_run_t:file { write unlink };

Comment 12 errata-xmlrpc 2013-02-21 08:27:54 UTC
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.