Hide Forgot
Description of problem: type=AVC msg=audit(1364317635.042:85663): avc: denied { search } for pid=15803 comm="freshclam" name="spool" dev=sda2 ino=1835534 scontext=system_u:system_r:freshclam_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_spool_t:s0 tclass=dir type=AVC msg=audit(1364317635.042:85663): avc: denied { search } for pid=15803 comm="freshclam" name="amavisd" dev=sda2 ino=1835258 scontext=system_u:system_r:freshclam_t:s0-s0:c0.c1023 tcontext=system_u:object_r:amavis_spool_t:s0 tclass=dir type=SYSCALL msg=audit(1364317635.042:85663): arch=c000003e syscall=42 success=yes exit=0 a0=5 a1=7fff34f77a40 a2=6e a3=10 items=0 ppid=15800 pid=15803 auid=0 uid=498 gid=498 euid=498 suid=498 fsuid=498 egid=498 sgid=498 fsgid=498 tty=(none) ses=10394 comm="freshclam" exe="/usr/bin/freshclam" subj=system_u:system_r:freshclam_t:s0-s0:c0.c1023 key=(null) Version-Release number of selected component (if applicable): selinux-policy-3.7.19-195.el6_4.3.noarch clamav-0.97.7-1.el6.x86_64 amavisd-new-2.8.0-4.el6.noarch How reproducible: Everytime, see above. Actual results: If you run an e-mail setup where Amavisd-New shall use Clamd for anti-virus scanning, this causes freshclam (which updates the clamav signature databases) to notify the clamd instance for amavisd-new via socket. And exactly this is forbidden due to the SELinux policy: system_u:system_r:clamd_t:s0 amavis 2150 0.0 1.6 372516 271168 ? Ssl Mar20 1:52 clamd.amavisd -c /etc/clamd.d/amavisd.conf --pid /var/run/amavisd/clamd.pid unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 16064 0.0 0.0 103248 836 pts/1 S+ 18:12 0:00 grep clam -rw-r-----. amavis amavis unconfined_u:object_r:amavis_var_run_t:s0 /var/run/amavisd/amavisd.lock -rw-r-----. amavis amavis system_u:object_r:amavis_var_run_t:s0 /var/run/amavisd/amavisd.pid -rw-rw-r--. amavis amavis system_u:object_r:amavis_var_run_t:s0 /var/run/amavisd/clamd.pid The separate clamd instance is shipped with the amavisd-new package from EPEL. Expected results: No AVC denied.
Note that clamd is not trying to scan the filesystem (as the setroubleshoot utility guesses) but freshclam tries to notify the clamav daemon process if the pid has been gathered (sorry, above was wrong, not socket, but it looks for the PID to signal it that way then).
Cross-filed case 00811010 in the Red Hat customer portal
We allow it in Fedora where we switched to antivirus_domain at all. I believe we can back port all antivirus changes to RHEL6.5.
What does antivirus_domain exactly do?
http://git.fedorahosted.org/cgit/selinux-policy.git/tree/antivirus.te?h=master_contrib
Hum? selinux-policy-targeted-3.7.19-195.el6_4.3.noarch ships antivirus 1.0.0 as per "semodule -l", however we still have the issue mentioned in description.
If I get you right, we should use boolean antivirus_can_scan_system, even if we do not want to allow scanning of whole system, but only want to achieve that notification of a specific clamd instance for amavisd-new works?! Is there no more fine granulation? Or did I misget you?
(In reply to comment #6) > Hum? selinux-policy-targeted-3.7.19-195.el6_4.3.noarch ships antivirus 1.0.0 > as per "semodule -l", however we still have the issue mentioned in > description. Right, but it just contains labeling for /var/opt/f-secure(/.*)? gen_context(system_u:object_r:antivirus_db_t,s0) and allows all antivirus domains to access this dir.
I agree that the boolean antivirus_can_scan_system solves the initial issue for ClamAV - but it grants a bit more than least privilege in this case. Even F-Secure works as expected (because you mentioned it in comment #8, but you need to enable the boolean amavis_use_jit due to execmem in fsav(d). Okay. I personally can deal with relatively loose antivirus_can_scan_system boolean even I expected something more tight/fine granulated.
After examining all of the policy the difference in Access was not considered that great and the number of AVC's being generated from people combining different technologies was just getting in the way of people using SELinux. Some times we get too fine grained of controls and it causes more problems then the security it actually provides. Handling of spam was consolodated a few years ago also.
Daniel, thanks for the explanation. For me the issue would be solved hereby, but I would ask for a more proper documentation, which clearly states that boolean antivirus_can_scan_system does not only do what the name says, but also might be needed in case that the anti-virus components need to access other parts of the filesystem for non-scanning (!) actions. The current antivirus.te in a fully up-to-date RHEL 6.5 works fine here. You also might add to the boolean documentation of amavis_use_jit, that it might be used in conjunction if the anti-virus software in general uses a execmem call and is called in the context of amavisd-new. To make it even more perfect, you could add that for running the "F-Secure Linux Security" together with amavisd-new, you must use booleans antivirus_can_scan_system and amavis_use_jit. But this also could go into a knowledgebase (KB) entry. I guess this needs to be done by another team, not by you technical guys; shall I copy this also into the regular ticket or will somebody pick it up?
Miroslav can you add this documentation.
I merged all antivirus domains to antivirus_t. Basically it will be a part of errata doc.
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-1598.html