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(a)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(a)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.
-----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-----