On Tue, 15 Jan 2008 14:53:18 -0500
Daniel J Walsh <dwalsh(a)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(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.
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-----