Re: Sendmail milters in Fedora 8

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----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@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.
> 
> 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@xxxxxxxxxxxxxxxxx>) 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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkeNDy0ACgkQrlYvE4MpobOJIACfYIuXiAVS506Wzv42LeBrwxdD
hxkAoOXxP5M55WXgf/qVNZE0lqt+/uZZ
=prIg
-----END PGP SIGNATURE-----

--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux