Postfix/mailman problem

[Eric Smith]

I've got an FC4 x86_64 system with the targeted policy.  I'm only
just beginning to understand SELinux, after reading the O'Reilly book.

I'm trying to use the Postfix MTA with GNU Mailman, using the
postfix-to-mailman-2.1.py script.  I put the script in
/usr/lib/mailman/bin, but it fails.  /var/log/maillog says:

Mar  1 17:26:34 donnybrook pipe[10056]: fatal: pipe_comand: execvp
/usr/lib/mailman/bin/postfix-to-mailman-2.1.py: Permission denied
Mar  1 17:26:35 donnybrook postfix/pipe[10055]: 4D0F150087:
to=<nonpareil-commits(a)lists.brouhaha.com>, relay=mailman, delay=1,
status=bounced (Command died with status 1:
"/usr/lib/mailman/bin/postfix-to-mailman-2.1.py")

/var/log/audit/audit.log says:

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?

Thanks!
Eric

[Eric Smith]

I wrote about trying to get Postfix working with Mailman:
>  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? 
I found that if I turned off enforcing the chcon would succeed.

However, when I turn enforcing back on, Postfix is still unable
to invoke the postfix-to-mailman script.  With enforcing off, it
works fine, so I'm really curious as to what I need to do to make
it work properly with enforcing on.

Thanks,
Eric

[Ivan Gyurdiev]

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

[Eric Smith]

>  I haven't worked on the postfix pipe policy, but it seems like
> the only
>  thing it can execute at the moment is procmail. 
How is that determined?  I can't find a single reference to procmail
anywhere in the SELinux targeted configuration, and procmail doesn't
seem to have any special context:

# ls --lcontext /usr/bin/procmail
-rwxr-xr-x  1 system_u:object_r:bin_t          root mail 100680 Mar 18 
2005 /usr/bin/procmail

>  I would say:
>  - the type mailman_queue_exec_t looks wrong for that file - how did it
>  get this type? 
I'm not sure, actually.  Should it just be system_u:object_r:bin_t?

>  - 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. 
Should I change its context to system_u:object_r:bin_t?

>  In the short run, maybe a macro can be added to postfix that takes a
>  domain and allows postfix_pipe to run that. 
Makes sense.  I don't have any idea how to do it, though perhaps I can
find time this weekend to study the O'Reilly book more.

Thanks!
Eric

[Eric Smith]

Ivan wrote:
>  - the type mailman_queue_exec_t looks wrong for that file - how did
> it
>  get this type? 
And I said that I don't know.  Actually, the entire /usr/lib/mailman
directory somehow got its contexts screwed up, and I ran restorecon.
Maybe it set that context on the postfix-to-mailman script, on the
basis of the execute permission being set?  Otherwise I still have no
clue.

Eric

[Ivan Gyurdiev]

>  How is that determined?  I can't find a single reference to
> procmail
>  anywhere in the SELinux targeted configuration, and procmail doesn't
>  seem to have any special context:
>
>  # ls --lcontext /usr/bin/procmail
>  -rwxr-xr-x  1 system_u:object_r:bin_t          root mail 100680 Mar 18 
>  2005 /usr/bin/procmail
>     
I run strict policy, you probably don't have a procmail policy installed.
I determined this by running looking at the policy.conf in the generated 
policy.conf file from a refpolicy cvs build. I also looked at the policy 
source.

        allow postfix_pipe_t postfix_pipe_exec_t:file { read getattr 
lock execute ioctl };
        allow postfix_pipe_t postfix_pipe_exec_t:file { { read getattr 
lock execute ioctl } execute_no_trans };
        allow postfix_pipe_t postfix_exec_t:file { read getattr lock 
execute ioctl };
        allow postfix_pipe_t shell_exec_t:file { { read getattr lock 
execute ioctl } execute_no_trans };
        allow postfix_pipe_t ld_so_t:file { read getattr lock execute 
ioctl };
        allow postfix_pipe_t { shlib_t textrel_shlib_t }:file { read 
getattr lock execute ioctl };
        allow postfix_pipe_t procmail_exec_t:file { getattr read execute };

        type_transition postfix_pipe_t var_run_t:file postfix_var_run_t;
        type_transition postfix_master_t postfix_pipe_exec_t:process 
postfix_pipe_t;
        type_transition postfix_pipe_t procmail_exec_t:process procmail_t;

> > I would say:
> > - the type mailman_queue_exec_t looks wrong for that file - how did it
> > get this type?
> >     
>
>  I'm not sure, actually.  Should it just be system_u:object_r:bin_t?
>     
Did you install this file yourself? bin_t certainly seems more correct...
But it doesn't really matter what it is - pipe still won't be able to 
transition into the mailman domain until policy is written for that.

> > - 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.
> >     
>
>  Should I change its context to system_u:object_r:bin_t?
>     
Anything you change that is not a customizable type can later get 
un-done by restorecon.
This should be fixed in policy.

[Ivan Gyurdiev]

>  And I said that I don't know.  Actually, the entire
> /usr/lib/mailman
>  directory somehow got its contexts screwed up, and I ran restorecon.
>  Maybe it set that context on the postfix-to-mailman script, 
I don't see that
script in the current mailman package.

>   on the
>  basis of the execute permission being set?  
Contexts should be set in the following
way [ to the best of my 
knowledge...could be wrong ]
==============================================
- if the creating program calls setfscreatecon() in libselinux, the next 
created file has that type

- if a rule exists in policy which maps the pair (src_con, target_class) 
-> target_con, then the object of type target_class created by a process 
in src_con gets its context changed to target_con. This is an automatic 
transition.

- otherwise, the context is set to match the context of the parent directory

[Eric Smith]

Ivan wrote:
>  - the file /usr/lib/mailman/mail (which your script runs) appears to
> be
>  a SGID executable to group mailman which runs other [mailman] programs. 
[...]
>  ultimately this boils down to postfix_pipe being unable to execute
>  mailman. 
However, it isn't even able to invoke the python script.  To make that
work, does the policy need to allow postfix_pipe_t to run python?

The python script isn't that complicated; I could rewrite it in C if
necessary.

I tried my hand at adding mailman rules to postfix.te:

ifdef(`mailman.te', `
domain_auto_trans(postfix_pipe_t, mailman_exec_t, mailman_t)
')

but that doesn't appear to work, possibly because mailman.te defines
mailman_$1_t, and I don't have any idea what $1 is.

Thanks,
Eric

[and thanks for putting up with my SELinux newbie questions!]

[Ivan Gyurdiev]

>  However, it isn't even able to invoke the python script.  To make
> that
>  work, does the policy need to allow postfix_pipe_t to run python?
>     
Yes. It seems like it's currently able to run shells (shell_exec_t).
Doesn't appear like it can run python (bin_t).
>  The python script isn't that complicated; I could rewrite it in C
> if
>  necessary.
>     
This shouldn't be necessary.
>  I tried my hand at adding mailman rules to postfix.te:
>
>  ifdef(`mailman.te', `
>  domain_auto_trans(postfix_pipe_t, mailman_exec_t, mailman_t)
>  ')
>
>  but that doesn't appear to work,  
When you say something doesn't work, that
could mean anything - to find 
out what is going on, you need to look at the audit log, and see exactly 
what is denied. Then you can try to write policy to fix it.

Also, I think enumerating what can be run in the postfix policy is not a 
very good idea - should have a macro instead, to be called by client 
domains. The macro would go into postfix.if.

>  possibly because mailman.te defines
>  mailman_$1_t, and I don't have any idea what $1 is.
>     
That's probably defined inside an m4 macro of some sort.
$1 expands to the first argument of that macro - it's a variable.
Usually it stands for a "prefix", which most of the time simply means a 
selinux role (user, staff, or sysadm)
To find out for sure you have to grep for that macro, and see what 
argument it's called with.
The XML spec in the .if file should explain what each argument stands for.

[Eric Smith]

Ivan wrote:
>  Yes. It seems like it's currently able to run shells
> (shell_exec_t).
>  Doesn't appear like it can run python (bin_t). 
Hmmm...  maybe Python should be considered a shell?  From the POV of
SELinux policy, is the defining characteristic of a shell that it is
interactive, or that it runs scripts?  I notice that the bash has
shell_exec_t, which csh has only bin_t.

>  Also, I think enumerating what can be run in the postfix policy is
> not a
>  very good idea - should have a macro instead, to be called by client
>  domains. The macro would go into postfix.if. 
Sure, but my immediate goal is to find the simplest way to change it
such that I can turn enforcing back on again on my server.  While it
would be great to do it in a correct and elegant manner, I think it's
going to be a while before I understand this stuff well enough to do
that.

Eric

[Daniel J Walsh]

Eric Smith wrote:
>  Ivan wrote:
>    
> > Yes. It seems like it's currently able to run shells (shell_exec_t).
> > Doesn't appear like it can run python (bin_t).
> >     
>
>  Hmmm...  maybe Python should be considered a shell?  From the POV of
>  SELinux policy, is the defining characteristic of a shell that it is
>  interactive, or that it runs scripts?  I notice that the bash has
>  shell_exec_t, which csh has only bin_t.
>
>    
> > Also, I think enumerating what can be run in the postfix policy is not a
> > very good idea - should have a macro instead, to be called by client
> > domains. The macro would go into postfix.if.
> >     
>
>  Sure, but my immediate goal is to find the simplest way to change it
>  such that I can turn enforcing back on again on my server.  While it
>  would be great to do it in a correct and elegant manner, I think it's
>  going to be a while before I understand this stuff well enough to do
>  that.
>
>  Eric
>
>     
Changes in latest policy 2.2.23-15 should allow postfix to communicate 
with mailman_queue_exec_t
>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>

[Eric Smith]

Daniel J Walsh wrote:
>  Changes in latest policy 2.2.23-15 should allow postfix to
> communicate
>  with mailman_queue_exec_t 
Thanks!  I tried to build and install that on FC4 last night, but ran
into too many problems with prerequisites.  I was able to build many of
the prerequisites, but I ran into non-obvious problems with one of them.

I plan to upgrade the server to FC5 when that is released, so I'll trying
installing the new policy on it at that time, since I expect I won't have
nearly as much trouble with prerequisites on that.

It occurs to me that the other thing that I'll eventually want to run
from Postfix pipe is Spamassassin.  I haven't tried that yet, but it
looks like the FC4 targeted policy won't allow it.  Can you please add
that to a future version?

Best regards,
Eric