postfix, procmail and SELinux - No Go

[Paul Howarth]

Marc Schwartz (via MN) wrote:
> On Wed, 2006-06-21 at 15:43 +0100, Paul Howarth wrote:
>> Marc Schwartz (via MN) wrote:
>>> On Wed, 2006-06-21 at 08:20 +0100, Paul Howarth wrote:
>>>> OK, here's an updated version of mypyzor.te:
>>>>
>>>> policy_module(mypyzor, 0.1.3)
>>>>
>>>> require {
>>>>         type pyzor_t;
>>>>         type pyzor_exec_t;
>>>>         type pyzor_port_t;
>>>>         type spamd_t;
>>>> };
>>>>
>>>> # temp files
>>>> type pyzor_tmp_t;
>>>> files_tmp_file(pyzor_tmp_t)
>>>>
>>>> # Allow pyzor to create and use temp files and dirs
>>>> allow pyzor_t pyzor_tmp_t:dir create_dir_perms;
>>>> allow pyzor_t pyzor_tmp_t:file create_file_perms;
>>>> files_type(pyzor_tmp_t)
>>>> files_tmp_filetrans(pyzor_t, pyzor_tmp_t, { file dir })
>>>>
>>>> # Allow pyzor to read config (and any other file...)
>>>> # from user home directories
>>>> userdom_read_unpriv_users_home_content_files(pyzor_t)
>>>>
>>>> # Allow pyzor to read /dev/urandom
>>>> dev_read_urand(pyzor_t)
>>>>
>>>> # Allow pyzor to send and receive pyzor messages!
>>>> allow pyzor_t pyzor_port_t:udp_socket send_msg;
>>>> allow pyzor_t pyzor_port_t:udp_socket recv_msg;
>>>>
>>>> # Allow spamd to signal pyzor (kill/hup ?)
>>>> allow spamd_t pyzor_t:process signal;
>>>>
>>>> # This doesn't seem to break anything
>>>> dontaudit spamd_t pyzor_exec_t:file getattr;
>>>>
>>>> # Allow pyzor to ...?
>>>> corecmd_search_bin(pyzor_t)
>>>> kernel_read_kernel_sysctls(pyzor_t)
>>>> # It does a getattr on /usr/bin/time for reasons unknown...
>>>> # Would be nice to know if changing these from
>>>> # allow to dontaudit causes any breakage
>>>> allow pyzor_t bin_t:dir getattr;
>>>> allow pyzor_t bin_t:file getattr;
>>>>
>>>> # Pyzor/python probably doesn't need to be able to read /proc/meminfo
>>>> kernel_dontaudit_list_proc(pyzor_t)
>>>> kernel_dontaudit_read_system_state(pyzor_t)
>>> Paul,
>>>
>>> I have made the change and all seems well so far.
>>>
>>> Note that the version you have above is the same as the prior version.
>>> So I bumped it 0.2.0 arbitrarily, unless you have an alternative
>>> versioning schema that you want to stay with.
>> Whoops. I've updated my copy now so we should stay in sync. Could you 
>> try bumping the version again and removing these lines:
>>
>> allow pyzor_t bin_t:dir getattr;
>> allow pyzor_t bin_t:file getattr;
>>
>> I'd like to see if things still work. If so, we can dontaudit these 
>> instead of allowing them.
>>
>> Similarly, can you try removing the mypostfix module (semodule -r 
>> mypostfix) and see if things still work? The strange AVC of 
>> postfix_master_t reading the manpage should reappear and it would be 
>> interesting to see if it broke in some way in enforcing mode.
> 
> OK.  Commented out the above lines in mypyzor.te (v 0.2.1) and removed
> mypostfix.
> 
> The current modules then are:
> 
> # semodule -l
> amavis  1.0.4
> clamav  1.0.1
> myclamscan      0.2.0
> mydcc   0.1.3
> mypyzor 0.2.1
> procmail        0.5.3
> pyzor   1.0.1
> 
> 
> No msgs are being reported by avclist subsequent to the above changes.
> Specifically nothing wrt the postfix manpage weirdness.
> 
> All else appears to be OK so far.

Can you try restarting postfix? I think the manpage thing happened at 
that point.

Once that's done I'd like to try out the dcc and razor modules that are 
now in rawhide. That will involve going back to permissive mode for a 
while though.

Paul.

Paul.