Clamd getting out of hand...

[Arthur Dent]

Hello All,

I have been using SELinux in enforcing mode on my F8 box for some time
now. I had to go through a bit of pain to get clamassassin working with
clamd to scan my emails but it worked OK.

This weekend I upgraded to F9 and have now had about a gazillion AVC
denials related to clamd.

I have therefore been forced to use audit2allow to add to the already
pretty cumbersome local policy I had with F8.

I list the policy below. All of the entries are as a result of some
denial and subsequent audit2allow policy generation.

My question is basically - can one of you gurus tell me if all this
stuff is still necessary? Is there a policy in the works that might 
avoid all this?

Thanks in advance

AD


##########################################
# cat myclamd.te
policy_module(myclamd, 1.1.11)
require {
        type clamscan_t;
        type clamd_t;
        class tcp_socket { write create connect };
	type var_run_t;
        type user_home_t;
        class sock_file { write unlink create };
        class file append;
	type unlabeled_t;
        class association recvfrom;

}

#============= clamd_t ==============
allow clamd_t var_run_t:sock_file { unlink create };
corenet_tcp_bind_generic_port(clamd_t)
userdom_read_generic_user_home_content_files(clamd_t)

#============= clamscan_t ==============
allow clamscan_t self:tcp_socket { write create connect };
allow clamscan_t user_home_t:file append;
allow clamscan_t var_run_t:sock_file write;
corenet_tcp_connect_generic_port(clamscan_t)
corenet_sendrecv_unlabeled_packets(clamscan_t)
mta_read_queue(clamscan_t)
procmail_rw_tmp_files(clamscan_t)
userdom_read_generic_user_home_content_files(clamscan_t)
allow clamscan_t unlabeled_t:association recvfrom;
########################################## 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-selinux-list/attachments/20080727/4fee1b8e/attachment.sig>