Sendmail milters in Fedora 8
Daniel J Walsh
dwalsh at redhat.com
Wed Jan 16 11:23:04 UTC 2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Paul Howarth wrote:
> On Tue, 15 Jan 2008 14:53:18 -0500
> Daniel J Walsh <dwalsh at redhat.com> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Paul Howarth wrote:
>>> Daniel J Walsh wrote:
>>>> -----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 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.
>>>>>
>>>> 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.
>>> I don't think it's a leaked file descriptor - that would be
>>> dontaudit-able, right? By not allowing communications with the
>>> initrc_t:unix_stream_socket, the milter fails to work:
>>>
>>> ==> /var/log/audit/audit.log <==
>>> type=AVC msg=audit(1200408212.783:142453): avc: denied
>>> { connectto } for pid=7805 comm="sendmail"
>>> path="/var/spool/milter-regex/sock"
>>> scontext=system_u:system_r:sendmail_t:s0
>>> tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket
>>> type=SYSCALL msg=audit(1200408212.783:142453): arch=40000003
>>> syscall=102 success=no exit=-13 a0=3 a1=bfd9f600 a2=b7f79bd4 a3=0
>>> items=0 ppid=7764 pid=7805 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0
>>> egid=51 sgid=51 fsgid=51 tty=(none) comm="sendmail"
>>> exe="/usr/sbin/sendmail.sendmail"
>>> subj=system_u:system_r:sendmail_t:s0 key=(null)
>>>
>>> ==> /var/log/maillog <==
>>> Jan 15 14:43:32 goalkeeper sendmail[7805]: NOQUEUE: connect from
>>> ard120.neoplus.adsl.tpnet.pl [83.26.189.120]
>>> Jan 15 14:43:32 goalkeeper sendmail[7805]: AUTH: available
>>> mech=CRAM-MD5 DIGEST-MD5, allowed mech=CRAM-MD5 DIGEST-MD5 LOGIN
>>> PLAIN Jan 15 14:43:32 goalkeeper sendmail[7805]: m0FEhW21007805:
>>> Milter (milter-regex): error connecting to filter: Permission denied
>>> Jan 15 14:43:32 goalkeeper sendmail[7805]: m0FEhW21007805: Milter
>>> (milter-regex): to error state
>>> Jan 15 14:43:32 goalkeeper sendmail[7805]: m0FEhW21007805: Milter:
>>> initialization failed, temp failing commands
>>> Jan 15 14:43:32 goalkeeper sendmail[7805]: m0FEhW21007805: SMTP MAIL
>>> command (<pathrusim at zombanewmedia.com>) from
>>> ard120.neoplus.adsl.tpnet.pl [83.26.189.120] tempfailed (due to
>>> previous checks)
>>>
>>>
>>> The initrc_t type shows up in netstat but not in ls:
>>> # netstat -aZp | grep initrc
>>> tcp 0 0 goalkeeper.intra.:bacula-fd *:* LISTEN
>>> 5864/bacula-fd system_u:system_r:initrc_t:s0
>>> udp 0 0 rbldns.intra.cit:domain *:*
>>> 5885/rbldnsd system_u:system_r:initrc_t:s0
>>> 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
>>> unix 2 [ ] DGRAM 2150436
>>> 5779/milter-regex system_u:system_r:initrc_t:s0
>>> unix 2 [ ] DGRAM 14141
>>> 5853/spamass-milter system_u:system_r:initrc_t:s0
>>> # ls -lZ /var/run/spamass-milter/spamass-milter.sock
>>> /var/spool/milter-regex/sock
>>> srwxr-xr-x sa-milt sa-milt system_u:object_r:spamd_var_run_t:s0
>>> /var/run/spamass-milter/spamass-milter.sock
>>> srw------- mregex mregex system_u:object_r:spamd_var_run_t:s0
>>> /var/spool/milter-regex/sock
>>>
>>>
>>> Paul.
>>>
>>>
>> Ok then I guess we need to label
>>
>> chcon -t spamd_exec_t /usr/sbin/spamass-milter
>>
>> And then build policy off of that.
>
> Whilst that might result in a solution for spamass-milter, it's not
> going to help milter-regex or potentially any other milter (they're all
> likely to use the same libmilter [sendmail] API for setting up the
> sockets).
>
> There seems to be something odd about sockets in general; the netstat
> output quoted above shows a couple of network-listening sockets with
> type initrc_t too, from a further two non-milter programs, namely
> bacula and rbldnsd. I also see the same issue with nasd and rpc.quotad.
> though I can also see a bunch of listening sockets with
> system_u:system_r:unconfined_t on my desktop.
>
> Why might some of these apps transition to unconfined_t and others not?
>
> And why does "ls" show a different type than "netstat"?
>
> Paul.
ls is showing file context and netstat is showing processes.
Processes running as unconfined_t were started by unconfined_t without
going through an initrc_exec_t type. So either you started these
processes directly or the label of their start up script is wrong
ls -lZ /etc/init.d/*
restorecon -R -v /etc/init.d
Should fix.
So we need to allow sendmail to read sockets setup by initrc_t?
Adding
init_stream_connect_script(mailserver_delivery)
init_rw_script_stream_sockets(mailserver_delivery)
Will allow all programs that deliver mail to read/write/connectto
initrc_t unix_stream_sockets.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkeN6RgACgkQrlYvE4MpobPmKQCdGdL26St7vIulDPItjbYlo19U
NJoAoJUKSnILXvPG15XjHH+53icvmsMd
=LpHn
-----END PGP SIGNATURE-----
More information about the fedora-selinux-list
mailing list