Bug 414891

Here are the audit messages I get, in particular, on RHEL5:

type=AVC msg=audit(1196975865.063:103435): avc:  denied  { create } for 
pid=13559 comm="deliver" scontext=user_u:system_r:dovecot_deliver_t:s0
tcontext=user_u:system_r:dovecot_deliver_t:s0 tclass=unix_dgram_socket


type=AVC msg=audit(1196976790.677:103459): avc:  denied  { getattr } for 
pid=14241 comm="deliver" path="/tmp" dev=sda3 ino=48955393
scontext=user_u:system_r:dovecot_deliver_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=dir

And after those are handled, I get:

type=AVC msg=audit(1196980271.577:79): avc:  denied  { connect } for  pid=4121
comm="deliver" scontext=system_u:system_r:dovecot_deliver_t:s0
tcontext=system_u:system_r:dovecot_deliver_t:s0 tclass=unix_dgram_socket

And also:

type=AVC msg=audit(1196981326.569:87): avc:  denied  { write } for  pid=4480
comm="deliver" name="log" dev=tmpfs ino=6268
scontext=system_u:system_r:dovecot_deliver_t:s0
tcontext=system_u:object_r:devlog_t:s0 tclass=sock_file

And a few more:


type=AVC msg=audit(1196981431.525:90): avc:  denied  { sendto } for  pid=4530
comm="deliver" path="/dev/log" scontext=system_u:system_r:dovecot_deliver_t:s0
tcontext=system_u:system_r:syslogd_t:s0 tclass=unix_dgram_socket

type=AVC msg=audit(1196981498.470:94): avc:  denied  { write } for  pid=4561
comm="deliver" scontext=system_u:system_r:dovecot_deliver_t:s0
tcontext=system_u:system_r:dovecot_deliver_t:s0 tclass=unix_dgram_socket

Some of these extra ones allow deliver to write to syslog.

If you create a policy module with

policy_module(mydovecot, 1.0)
gen_requires(`
                 type dovecot_deliver;
')

allow dovecot_deliver_t self:unix_dgram_socket create_socket_perms;
logging_send_syslog_msg(dovecot_deliver_t)


Compile and install it, does it solve your problem?

(In reply to comment #4)
> If you create a policy module with
> 
> policy_module(mydovecot, 1.0)

  I get a syntax error on that. (And I'm not familiar enough with the .te syntax
to know why.)

Created attachment 280631 [details]
My local.te

FWIW, this is the local.te that audit2allow generated for me based on the audit
messages I pasted here in this bug.

Fixed in selinux-policy-2.4.6-107.el5

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.

Created attachment 284491 [details]
Complete Audit Messages

So, for messages below 256K, dovecot's deliver holds them only in memory, and
you just get the audit messages above.

However, for messages above 256K, it writes them to /tmp. Thus there are more
audit messages generated. I was getting lots of delivery failures locally and
wasn't sure why until I found these audit messages.

Then this is really a bug in dovecot then, since no system service should write
to /tmp.  /tmp can be written to by users so therefore it should only be written
to by users.  Dovecot should write to /var/run for any temporary storage.

I will fix selinux policy to allow this in RHEL5 but this should be fixed in
future versions of dovecot.

Fixed in selinux-policy-2.4.6-107.el5

(In reply to comment #10)
> Then this is really a bug in dovecot then, since no system service should write
> to /tmp.  /tmp can be written to by users so therefore it should only be written
> to by users.  Dovecot should write to /var/run for any temporary storage.

  Hrm, or maybe /var/spool/ would be more appropriate. That's what the other
mail services do.

Fixed in selinux-policy- 2.4.6-127

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