Bug 437646 - selinux denials running clamscan from script called from ~/.forward
selinux denials running clamscan from script called from ~/.forward
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
8
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-15 14:00 EDT by David Baron
Modified: 2008-11-17 17:03 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-11-17 17:03:18 EST
Type: ---
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 David Baron 2008-03-15 14:00:48 EDT
Description of problem:  selinux gives a bunch of denials to clamscan when it is
run from a script invoked from ~/.forward .

Version-Release number of selected component (if applicable):
selinux-policy-3.0.8-87.fc8
selinux-policy-targeted-3.0.8-87.fc8
clamav-0.92.1-1.fc8
postfix-2.4.5-2.fc8

How reproducible: always

Steps to Reproduce:
I have mail delivery set up to run clamscan on messages via a script called from
by ~/.forward file, which is just:

|"/bin/bash ~/bin/forward-normal.sh"

then forward-normal.sh puts the message in a tempfile, calls clamscan on it, and
invokes procmail with different procmailrc files depending on the result.  (I
wanted a better way to do this without installing postfix extensions for which
Fedora doesn't have RPMs, but I couldn't find one, at least back when I set this
up a few years ago.)


Actual results:
Doing this causes selinux to deny four different things (I have it in
non-enforcing mode because of this):

It gives the following denial once per processing of mail:

type=AVC msg=audit(1205603193.508:210): avc:  denied  { getattr } for  pid=2476
comm="bash" path="/usr/bin/clamscan" dev=sda3 ino=882983
scontext=system_u:system_r:postfix_local_t:s0
tcontext=system_u:object_r:clamscan_exec_t:s0 tclass=file

and then gives the following three once per message, I think:

type=AVC msg=audit(1205603193.510:211): avc:  denied  { execute } for  pid=2476
comm="bash" name="clamscan" dev=sda3 ino=882983
scontext=system_u:system_r:postfix_local_t:s0
tcontext=system_u:object_r:clamscan_exec_t:s0 tclass=file

type=AVC msg=audit(1205603193.510:212): avc:  denied  { read } for  pid=2476
comm="bash" name="clamscan" dev=sda3 ino=882983
scontext=system_u:system_r:postfix_local_t:s0
tcontext=system_u:object_r:clamscan_exec_t:s0 tclass=file

type=AVC msg=audit(1205603193.510:213): avc:  denied  { execute_no_trans } for 
pid=2479 comm="bash" path="/usr/bin/clamscan" dev=sda3 ino=882983
scontext=system_u:system_r:postfix_local_t:s0
tcontext=system_u:object_r:clamscan_exec_t:s0 tclass=file


Expected results:  No selinux denials (so I can run in enforcing mode).


(I'm really not sure if this is supposed to work, though it seems like clamscan
ought to be allowed to be run from things running in postfix context; I don't
actually know what causes the context for what's currently executing to switch
or if I should somehow be doing that manually -- or even if that question really
makes sense.)
Comment 1 David Baron 2008-03-16 14:17:33 EDT
That said, I decided I don't particularly need this scanning any longer, so I
just stopped using it.  (All my mail seems to be virus-scanned upstream now,
which wasn't the case when I set it up.)

And if I want it again in the future I could probably just set up amavisd-new,
which wasn't packaged for Fedora at the time I set this up originally (although
it looks like it could be a bit of work to set up).
Comment 2 Daniel Walsh 2008-03-17 09:24:13 EDT
Does not seem like an unreasonable thing to do, so I will allow it in 

Fixed in selinux-policy-3.0.8-94.fc8
Comment 3 Daniel Walsh 2008-11-17 17:03:18 EST
Closing all bugs that have been in modified for over a month.  Please reopen if the bug is not actually fixed.

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