-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Paul Howarth wrote:
> 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@xxxxxxxxxx
>>>>> 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.
>
Nope. I don't know what is running as initrc_t and I would bet this is
a leaked file descriptor. Or at least a redirectiron of stdin/stdout.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkeLuHkACgkQrlYvE4MpobO9mACfT1ADnAw71pvxJyaDoQM2o0WZ
LdIAoOYQe4Y05QfPzMaUjCFZ8z6Rz/C8
=OYMh
-----END PGP SIGNATURE-----
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
