Postfix/mailman problem

Ivan Gyurdiev ivg2 at cornell.edu
Thu Mar 2 19:02:10 UTC 2006


> type=AVC msg=audit(1141262794.346:48506): avc:  denied  { execute } for 
> pid=10056 comm="pipe" name="postfix-to-mailman-2.1.py" dev=dm-6 ino=786433
> scontext=system_u:system_r:postfix_pipe_t
> tcontext=system_u:object_r:mailman_queue_exec_t tclass=file
>
> As root, I tried:
> % chcon -u system_u -r system_r -t postfix_pipe_t postfix-to-mailman-2.1.py
> chcon: failed to change context of postfix-to-mailman-2.1.py to
> system_u:system_r:postfix_pipe_t: Permission denied
>
> Why can't I do that, or what should I do instead to make this work?
This is definitely wrong - postfix_pipe_t is a process domain type - you 
shouldn't mark files of this type.
I haven't worked on the postfix pipe policy, but it seems like the only 
thing it can execute at the moment is procmail.

I would say:
- the type mailman_queue_exec_t looks wrong for that file - how did it 
get this type?

- the file /usr/lib/mailman/mail (which your script runs) appears to be 
a SGID executable to group mailman which runs other [mailman] programs. 
It has type lib_t, which is incorrect. I think whatever regexps are 
currently used in policy are overly generic, and misclassify lots of 
things as lib_t.  (1) the regexp should be made more specific, and 
either (2) the file should be properly labeled with its own expression 
match, or (3) the program should be made to use /bin and /sbin like 
everyone else.

- ultimately this boils down to postfix_pipe being unable to execute 
mailman. This is actually a more general problem - how do you confine a 
program, which allows the user to legitimately configure running 
arbitrary things in multiple other domains (i.e. pipe)? The same problem 
exists for example in gnome-session. Do you try to enumerate what 
domains can and can't be ran in policy? Doesn't that limit the 
usefullness of the program? On the other hand we certainly don't want 
important daemons to run whatever they want to - the point of selinux is 
confinement, so a program which is taken over can't get out of control.

In the short run, maybe a macro can be added to postfix that takes a 
domain and allows postfix_pipe to run that. Same for gnome session, if 
that's ever confined. The opposite approach (enumeration in the 
executing program) seems wrong, since it doesn't allow 3rd party 
integration.




More information about the selinux mailing list