Bug 474183

Adding Dan, any thoughts?

You can allow this for now.

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

Fixed in selinux-policy-3.5.13-30.fc10

I have also had this bug. I disabled selinux and spamassassin has since added

[root@sensi spamass-milter]# ls -laZ
drwx------  sa-milt sa-milt system_u:object_r:spamd_var_run_t:s0 .
drwxr-xr-x  root root system_u:object_r:var_run_t:s0   ..
drwxr-xr-x  sa-milt sa-milt unconfined_u:object_r:spamd_var_run_t:s0 .pyzor
drwx------  sa-milt sa-milt system_u:object_r:spamd_var_run_t:s0 .spamassassin
srwxr-xr-x  sa-milt sa-milt system_u:object_r:spamd_var_run_t:s0 spamass-milter.sock
[root@sensi spamass-milter]# cd .pyzor
[root@sensi .pyzor]# ls -laZ
drwxr-xr-x  sa-milt sa-milt unconfined_u:object_r:spamd_var_run_t:s0 .
drwx------  sa-milt sa-milt system_u:object_r:spamd_var_run_t:s0 ..
-rw-r--r--  sa-milt sa-milt system_u:object_r:spamd_var_run_t:s0 servers

to the /var/run/spamass-milter/ directory. The above contexts have been progressively modified with the following .te files:

mail.te

module local 1.0;

require {
	type spamc_t;
	type dhcpd_t;
	type var_lib_t;
	type freshclam_t;
	type spamd_var_run_t;
	class capability { dac_read_search dac_override };
	class dir { write search };
}

#============= dhcpd_t ==============
allow dhcpd_t self:capability { dac_read_search dac_override };

#============= freshclam_t ==============
allow freshclam_t var_lib_t:dir search;

#============= spamc_t ==============
allow spamc_t spamd_var_run_t:dir write;

mail1.te

module local 1.0;

require {
	type spamc_t;
	type spamd_var_run_t;
	class dir add_name;
}

#============= spamc_t ==============
allow spamc_t spamd_var_run_t:dir add_name;

mail2.te

module local 1.0;

require {
	type spamc_t;
	type spamd_var_run_t;
	class dir write;
}

#============= spamc_t ==============
allow spamc_t spamd_var_run_t:dir write;

Currently running selinux-policy.noarch 3.5.13-38.fc10

Currently about to generate selinux module for the latest se alert


Summary:

SELinux is preventing pyzor (spamc_t) "getattr" to
/var/run/spamass-milter/.pyzor/servers (spamd_var_run_t).

Detailed Description:

[SELinux is in permissive mode, the operation would have been denied but was
permitted due to permissive mode.]

SELinux denied access requested by pyzor. It is not expected that this access is
required by pyzor and this access may signal an intrusion attempt. It is also
possible that the specific version or configuration of the application is
causing it to require additional access.

Allowing Access:

Sometimes labeling problems can cause SELinux denials. You could try to restore
the default system file context for /var/run/spamass-milter/.pyzor/servers,

restorecon -v '/var/run/spamass-milter/.pyzor/servers'

If this does not work, there is currently no automatic way to allow this access.
Instead, you can generate a local policy module to allow this access - see FAQ
(http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable
SELinux protection altogether. Disabling SELinux protection is not recommended.
Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi)
against this package.

Additional Information:

Source Context                system_u:system_r:spamc_t:s0
Target Context                system_u:object_r:spamd_var_run_t:s0
Target Objects                /var/run/spamass-milter/.pyzor/servers [ file ]
Source                        pyzor
Source Path                   /usr/bin/python2.5
Port                          <Unknown>
Host                          sensi.n-ksquires.id.au
Source RPM Packages           python-2.5.2-1.fc10
Target RPM Packages           
Policy RPM                    selinux-policy-3.5.13-38.fc10
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Permissive
Plugin Name                   catchall_file
Host Name                     sensi.n-ksquires.id.au
Platform                      Linux sensi.n-ksquires.id.au
                              2.6.27.9-159.fc10.x86_64 #1 SMP Tue Dec 16
                              14:47:52 EST 2008 x86_64 x86_64
Alert Count                   9
First Seen                    Sun 25 Jan 2009 10:36:53 AM EST
Last Seen                     Sun 25 Jan 2009 01:57:16 PM EST
Local ID                      4c8a1a6a-d721-4a19-87ce-ed24b3f52c54
Line Numbers                  

Raw Audit Messages            

node=sensi.n-ksquires.id.au type=AVC msg=audit(1232855836.385:119): avc:  denied  { getattr } for  pid=10808 comm="pyzor" path="/var/run/spamass-milter/.pyzor/servers" dev=dm-0 ino=51094321 scontext=system_u:system_r:spamc_t:s0 tcontext=system_u:object_r:spamd_var_run_t:s0 tclass=file

node=sensi.n-ksquires.id.au type=SYSCALL msg=audit(1232855836.385:119): arch=c000003e syscall=4 success=yes exit=0 a0=889f80 a1=7fff3d49e3a0 a2=7fff3d49e3a0 a3=65767265732f726f items=0 ppid=3535 pid=10808 auid=4294967295 uid=492 gid=0 euid=492 suid=492 fsuid=492 egid=489 sgid=489 fsgid=489 tty=(none) ses=4294967295 comm="pyzor" exe="/usr/bin/python2.5" subj=system_u:system_r:spamc_t:s0 key=(null)

Latest version of the module file, mail3.te contains:

module local 1.0;

require {
	type spamc_t;
	type devpts_t;
	type var_lib_t;
	type sendmail_t;
	type samba_etc_t;
	type freshclam_t;
	type spamd_var_run_t;
	class dir { search add_name };
	class file { write getattr read create };
	class chr_file write;
}

#============= freshclam_t ==============
allow freshclam_t var_lib_t:dir search;

#============= sendmail_t ==============
allow sendmail_t devpts_t:chr_file write;
allow sendmail_t samba_etc_t:file { read getattr };

#============= spamc_t ==============
allow spamc_t spamd_var_run_t:dir add_name;
allow spamc_t spamd_var_run_t:file { write read create getattr };

This was generated following a system reboot.

It appears that the pyzor is using the run directory for variable and file storage and has not been set the right context. I also note that this policy I am using is after the fix policy.

Fixed in selinux-policy-3.5.13-42.fc10

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping