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@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
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
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.
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
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 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
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
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!]
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.
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
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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
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
selinux@lists.fedoraproject.org