Sendmail milters in Fedora 8

[Paul Howarth]

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.