FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Hardened

 
 
LinkBack Thread Tools
 
Old 08-06-2011, 04:50 PM
Mike Edenfield
 
Default Troubleshooting FIFO pipes with bad security contexts...

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_rrocmail_t
tcontext=system_u:system_rostfix_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_rostfix_master_t root 94r
FIFO 0,7 0t0 4235 pipe
master 2069 system_u:system_rostfix_master_t root 95w
FIFO 0,7 0t0 4235 pipe
qmgr 2074 system_u:system_rostfix_qmgr_t postfix 94r
FIFO 0,7 0t0 4235 pipe
qmgr 2074 system_u:system_rostfix_qmgr_t postfix 95w
FIFO 0,7 0t0 4235 pipe
tlsmgr 2178 system_u:system_rostfix_master_t postfix 94r
FIFO 0,7 0t0 4235 pipe
tlsmgr 2178 system_u:system_rostfix_master_t postfix 95w
FIFO 0,7 0t0 4235 pipe
pickup 9273 system_u:system_rostfix_pickup_t postfix 94r
FIFO 0,7 0t0 4235 pipe
pickup 9273 system_u:system_rostfix_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
 
Old 08-06-2011, 08:12 PM
Sven Vermeulen
 
Default Troubleshooting FIFO pipes with bad security contexts...

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_rrocmail_t
> tcontext=system_u:system_rostfix_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
 
Old 08-06-2011, 10:40 PM
Mike Edenfield
 
Default Troubleshooting FIFO pipes with bad security contexts...

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_rrocmail_t
> > tcontext=system_u:system_rostfix_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
 

Thread Tools




All times are GMT. The time now is 07:25 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org