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