Postfix/mailman problem

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