[gentoo-hardened] Troubleshooting FIFO pipes with bad security contexts...

[gentoo-hardened] Troubleshooting FIFO pipes with bad security contexts...

[Mike Edenfield]

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

The problem appears to be that the FIFO objects that postfix's master process 
is creating aren't getting the correct security context:

basement ~ # lsof -Z | grep pipe | grep 4235  
master     2069       system_u:system_r:postfix_master_t           root   94r     
FIFO                0,7      0t0       4235 pipe
master     2069       system_u:system_r:postfix_master_t           root   95w     
FIFO                0,7      0t0       4235 pipe
qmgr       2074       system_u:system_r:postfix_qmgr_t          postfix   94r     
FIFO                0,7      0t0       4235 pipe
qmgr       2074       system_u:system_r:postfix_qmgr_t          postfix   95w     
FIFO                0,7      0t0       4235 pipe
tlsmgr     2178       system_u:system_r:postfix_master_t        postfix   94r     
FIFO                0,7      0t0       4235 pipe
tlsmgr     2178       system_u:system_r:postfix_master_t        postfix   95w     
FIFO                0,7      0t0       4235 pipe
pickup     9273       system_u:system_r:postfix_pickup_t        postfix   94r     
FIFO                0,7      0t0       4235 pipe
pickup     9273       system_u:system_r:postfix_pickup_t        postfix   95w     
FIFO                0,7      0t0       4235 pipe

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 } ; 
   allow procmail_t user_home_t : fifo_file { ioctl read write create getattr 
setattr lock append unlink link rename open } ; 
   allow procmail_t procmail_t : fifo_file { ioctl read write getattr lock 
append open } ; 

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.)

--Mike

Re: [gentoo-hardened] Troubleshooting FIFO pipes with bad security contexts...

[Sven Vermeulen]

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

Re: [gentoo-hardened] Troubleshooting FIFO pipes with bad security contexts...

[Mike Edenfield]

On Saturday, August 06, 2011 10:12:39 PM Sven Vermeulen wrote:
> 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?

Hm. Not offhand, and for some reason it seems to have stopped trying to do it. 

The only connection I have between procmail and postfix is the usual:

main.cf:mailbox_command = /usr/bin/procmail -a "$EXTENSION"

I use procmail mostly for mailing list filtering but that appears to be working 
fine without any AVCs, so I'm not sure where these came from. I'll poke around 
some more and see if I can figure it out, but at least now I have a better idea 
what the policy is supposed to be doing :)

--Mike