On Sat, Aug 06, 2011 at 12:50:46PM -0400, Mike Edenfield wrote:
> I'm trying to chase down an AVC message coming from procmail. I'm having a
> problem figuring out how to research, troubleshoot, or fix bad FIFO pipe
> contexts.
>
> The AVC I get is:
>
> Aug 6 12:15:52 basement kernel: type=1400 audit(1312647352.712:9623): avc:
> denied { write } for pid=9816 comm="procmail" path="pipe:[4235]" dev=pipefs
> ino=4235 scontext=system_u:system_r:procmail_t
> tcontext=system_u:system_r:postfix_master_t tclass=fifo_file
Any idea what procmail is trying to do at this point?
> The problem appears to be that the FIFO objects that postfix's master process
> is creating aren't getting the correct security context:
[... postfix' master process has fifo objects of postfix_master_t ...]
That is to be expected. As far as I know, SELinux doesn't support type
transitions on fifo_file (yet). Only on processes and since 2.6.39 on
sockets as well.
> Procmail doesn't have access to the postfix_master_t domain, but it does have
> access to this:
>
> basement ~ # sesearch --allow -sprocmail_t -cfifo_file
> Found 4 semantic av rules:
> allow procmail_t postfix_local_t : fifo_file { ioctl read write getattr
> lock
> append open } ;
> allow procmail_t postfix_pipe_t : fifo_file { ioctl read write getattr
> lock
> append open } ;
These accesses come from the procmail_domtrans() interface, used to allow
postfix_local_t and postfix_pipe_t (which are, unsurprisingly, used by
postfix' local & pipe applications) to "transition" to procmail (meaning
they can spawn procmail and that procmail process will then run as
procmail_t).
> So, I'm assuming that postfix's FIFOs ought to be one of those two:
> postfix_local_t or postfix_pipe_t. Since procmail's being used here as the
> local
> delivery agent I was guessing postfix_local_t. But I can't figure out where
> that
> is supposed to happen. Is that something postfix is required to do manually,
> or
> should there be a transition rule for it? (sesearch didn't show any trans
> rules for either of those types.)
That's an incorrect assumption.
As far as I can see, there is no rule allowing procmail to interact with a
postfix_master_t fifo_file (which includes pipes).
You can of course always enhance the policy to support it, but it might be
good to know what procmail is doing.
If this is part of a script which runs as sysadm_t (just thinking out loud)
and which pipes some output to "postlog" so it doesn't have to provide a
logging method for itself, then the AVC denial is to be expected. If you
still want this to succeed, see if you can put a "cat" in between, so
instead of
procmail ... | postlog
use
procmail ... | cat | postlog
But again, please find out what procmail is doing so we can see that it gets
a proper fix ;-)
Wkr,
Sven Vermeulen
