Bug 416541

Created attachment 282021 [details]
Audit messages

Created attachment 282041 [details]
Correct Audit Messages

Oh, I had a few mislabeled files. These are the correct audit messages, ignore
the file I first posted.

Looks like dccproc also wants to setgid when spamassassin first starts up:

type=AVC msg=audit(1197123260.124:4227): avc:  denied  { setgid } for  pid=20268
comm="dccproc" capability=6 scontext=user_u:system_r:dcc_client_t:s0
tcontext=user_u:system_r:dcc_client_t:s0 tclass=capability

That's kind of funny, since dccproc isn't a persistent process. It doesn't try
to setgid when just processing messages. Maybe there's some config it has to
read as the spamassassin user or something.

For those interested, this is what spamassassin does with DCC when it first
starts up:

ec  8 08:20:16 control spamd[20530]: dcc: dccifd is not available: no r/w dccifd
socket found
Dec  8 08:20:16 control spamd[20530]: util: executable for dccproc was found at
/usr/bin/dccproc
Dec  8 08:20:16 control spamd[20530]: dcc: dccproc is available: /usr/bin/dccproc
Dec  8 08:20:16 control spamd[20530]: info: entering helper-app run mode
Dec  8 08:20:16 control spamd[20530]: dcc: opening pipe: /usr/bin/dccproc -H -x
0 < /tmp/.spamassassin20530u370xQtmp
Dec  8 08:20:16 control spamd[20532]: util: setuid: ruid=0 euid=0
Dec  8 08:20:16 control spamd[20530]: dcc: got response: X-DCC--Metrics:
control.trusthosting.net 1113; Body=many Fuz1=many Fuz2=many
Dec  8 08:20:16 control spamd[20530]: info: leaving helper-app run mode
Dec  8 08:20:16 control spamd[20530]: dcc: listed: BODY=999999/999999
FUZ1=999999/999999 FUZ2=999999/999999

Fixed in selinux-policy-2.4.6-107

ou can allow this for now by executing 

# audit2allow -M mypol -i /var/log/audit/audit.log 
# semodule -i mypol.pp

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

I have an additional message in my audit logs as of today:

type=AVC msg=audit(1197397990.246:11419): avc:  denied  { read } for  pid=29576
comm="dccproc" name="meminfo" dev=proc ino=4026531842
scontext=user_u:system_r:dcc_client_t:s0 tcontext=system_u:object_r:proc_t:s0
tclass=file

This one's happened several times today.

And now that that's allowed, I get this one:

type=AVC msg=audit(1197405257.573:11626): avc:  denied  { getattr } for  pid=875
comm="dccproc" path="/proc/meminfo" dev=proc ino=4026531842
scontext=root:system_r:dcc_client_t:s0 tcontext=system_u:object_r:proc_t:s0
tclass=file

Sorry for bringing these in one-by-one, but I don't really want to leave SELinux
off on my publicly-accessible server long enough to get the whole series of
messages for this intermittent denial.

And it looks like once per day spamd tries to signal dccproc, for some reason.
I'm guessing this happens if it's in the middle of processing and has to
restart, or something.

type=AVC msg=audit(1197447449.438:12026): avc:  denied  { signal } for  pid=536
comm="spamd" scontext=root:system_r:spamd_t:s0
tcontext=root:system_r:dcc_client_t:s0 tclass=process

Fixed in selinux-policy-2.4.6-108.el5

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2008-0465.html