Sendmail milters in Fedora 8

[Paul Howarth]

Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Paul Howarth wrote:
>> Hi Dan,
>>
>> Daniel J Walsh wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Paul Howarth wrote:
>>>> Paul Howarth wrote:
>>>>> Since upgrading my mail server from Fedora 7 to Fedora 8, I've come
>>>>> across some problems with the sockets used for communication between
>>>>> sendmail and two of the "milter" plugins I'm using with it, namely
>>>>> milter-regex and spamass-milter. It's very likely that other milters
>>>>> will have similar issues.
>>>>>
>>>>> The sockets used are created when the milter starts, as follows:
>>>>>
>>>>> milter-regex:
>>>>> /var/spool/milter-regex/sock (var_spool_t, inherited from parent
>>>>> directory)
>>>>>
>>>>> spamass-milter:
>>>>> /var/run/spamass-milter/spamass-milter.sock (spamd_var_run_t, in
>>>>> policy)
>>>>>
>>>>> These are pretty well the upstream locations, though I'm open to
>>>>> moving the milter-regex socket from /var/spool to /var/run or
>>>>> elsewhere for consistency.
>>>>>
>>>>> Since moving to Fedora 8, I've had to add the following to local
>>>>> policy to get these milters working:
>>>>>
>>>>> allow sendmail_t spamd_var_run_t:dir { search getattr };
>>>>> allow sendmail_t spamd_var_run_t:sock_file { getattr write };
>>>>> allow sendmail_t var_spool_t:sock_file { getattr write };
>>>>> allow sendmail_t initrc_t:unix_stream_socket { read write connectto };
>>>>>
>>>>> The last of these is the strangest, and relates to Bug #425958
>>>>> (https://bugzilla.redhat.com/show_bug.cgi?id=425958). Whilst the
>>>>> socket file itself has the context listed above, the unix domain
>>>>> socket that sendmail connects to is still initrc_t, as can be seen
>>>>> from the output of "netstat -lpZ":
>>>>>
>>>>> ...
>>>>> unix  2      [ ACC ]     STREAM     LISTENING     14142
>>>>> 5853/spamass-milter system_u:system_r:initrc_t:s0
>>>>> /var/run/spamass-milter/spamass-milter.sock
>>>>> unix  2      [ ACC ]     STREAM     LISTENING     13794
>>>>> 5779/milter-regex   system_u:system_r:initrc_t:s0
>>>>> /var/spool/milter-regex/sock
>>>>> ...
>>>>>
>>>>> So, my questions are:
>>>>>
>>>>> 1. Why are the sockets still initrc_t?
>>>>> 2. Is this a kernel issue or a userspace issue that should be fixed in
>>>>> the milters?
>>>>> 3. Should there be a standard place for milter sockets to live, and if
>>>>> so, where?
>>>>> 4. How come this worked OK in Fedora 7 and previous releases?
>>>> Looking at the source code for these applications, I see that both of
>>>> them use the smfi_setconn() function in the sendmail milter library to
>>>> set up the sockets. It's therefore likely that this problem is common to
>>>> all milter applications that use unix domain sockets.
>>>>
>>>> I'm now of the opinion that moving the directory locations for these
>>>> sockets is a bad idea - it would need corresponding changes in people's
>>>> sendmail configuration files, which would lead to problems for people
>>>> doing package updates, or installing from upstream sources. Setting
>>>> different context types for the directories (e.g. make
>>>> /var/spool/milter-regex spamd_var_run_t) would seem a better option,
>>>> along with policy tweaks to allow sendmail to do the permissions checks
>>>> and write to the sockets).
>>>>
>>>> I'm still confused about the initrc_t sockets though.
>>>>
>>>> Paul.
>>>>
>>>> -- 
>>>> fedora-selinux-list mailing list
>>>> fedora-selinux-list at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>>> Ok I will add this to the next update.
>> What exactly is "this"? The 4 "allow" rules mentioned above, the context
>> type change for /var/spool/milter-regex mentioned later, both?
>>
>> Cheers, Paul.
>>
> Context change for /var/spool/milter-regex to spamd_var_run_t.  sendmail
> can already use sockets in this directory.

So that includes the:

allow sendmail_t initrc_t:unix_stream_socket { read write connectto }

?

Cheers, Paul.