On 08/22/2010 11:29 AM, Arthur Dent wrote:
Hello all,
Since upgrading from F11 to F13 I still have 3 outstanding issues. 1 is
my earlier thread about mlogc which is still the subject of some
correspondence on the modsecurity list, another is a mysterious "leaked
file descriptor" AVC which has a permissive type anyway so I will worry
about that later (and may have stopped since the latest selinux policy
release) and that just leaves clamd... sigh...
The relationship between procmail and clamd and selinux always seems to
be a troubled one and I don't know why it should be so, but hey...
Every time I upgrade Fedora I go through this little dance - remove my
old home made clamd policy, run my fetchmail->procmail->clamd( and
spamd)-> dovecot mail-chain and see what AVCs emerge. I create a policy
using audit2allow, rinse, repeat until all AVCs go away.
So why not do it properly this time and help fix this upstream?
Can you remove your custom modules and enclose raw AVC denials please?
Well I have done that as usual, all the AVCs have gone away, but
still I
get this message in my logs:
X-virus-report: /usr/local/bin/clamdscan error 2
X-virus-checker-version: clamassassin 1.2.4 with clamdscan / ERROR: Can't connect to
clamd: Permission denied
But NO AVCs
I have proved that selinux is the culprit. Putting SEL into permissive
mode temporarily allows clamd to work as it should (but still no AVCs).
I am a little reluctant to do the "semodule -DB" to reveal any silent
denials as I get swamped with stuff (but if that's what it takes...)
In the meantime can anyone suggest any other approach?
Show us raw AVC denials, also for the rules you added below. Also use
semodule -DB to collect the AVC denials as it may reveal hidden denials.
Here is my current clamd module as created by audit2allow:
=========================8<========================================
# cat selinux/myclamd.te
module myclamd 13.1.3;
require {
type unconfined_t;
type var_run_t;
type clamd_var_run_t;
type initrc_t;
type procmail_t;
class sock_file write;
class unix_stream_socket connectto;
}
#============= procmail_t ==============
allow procmail_t initrc_t:unix_stream_socket connectto;
#!!!! This avc is allowed in the current policy
What is running initrc_t? Can you show the raw avc denial.
allow procmail_t unconfined_t:unix_stream_socket connectto;
#!!!! This avc is allowed in the current policy
allow procmail_t var_run_t:sock_file write;
Mislabeled sock file.
allow procmail_t clamd_var_run_t:sock_file write;
#!!!! This avc is allowed in the current policy
This does look legit to me
=========================8<========================================
Note - those comments are created by audit2allow.
Yes, those comments are annoying.
Thanks in advance...
Mark
--
selinux mailing list
selinux(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux