-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Paul Howarth wrote:
> Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Paul Howarth wrote:
>>> On Tue, 15 Jan 2008 14:53:18 -0500
>>> Daniel J Walsh <dwalsh@xxxxxxxxxx> 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@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.
>>> 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.
>
> I suspect that the stuff running in unconfined_t gets started as part of
> a Gnome session rather than via an initscript.
>
>> So we need to allow sendmail to read sockets setup by initrc_t?
>
> Is it true to say (I think it is) that any process started via an
> initscript that doesn't transition to another domain (e.g. stuff that
> nobody has written policy for yet) will be in initrc_t?
>
> If so, the following is currently needed.
>
>> 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.
>
> This looks right for now, though I'm tempted to hack together policy for
> my two milters at least. What I was thinking of was creating a
> milter_template along the lines of the apache_content_template that
> could be used as a starting point for milter applications (all of which
> will communicate with sendmail [and postfix too for that metter] in the
> same way), and then add on anything necessary for each individual milter
> (some of which would require nothing else, some would require database
> connectivity etc.).
>
> Paul.
>
Sounds good.
All daemons that do not have policy and start from init run as initrc_t
which is unconfined. The problem is that if they exec a domain that is
confined, the transition will happen, and the execed domain may need to
communicate back to the initrc_t domain. So allowing maildelivery to
communicate with initrc_t seems to make sense.
inetd runs unknown domains as inetd_child_t which is also unconfined.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkeODOAACgkQrlYvE4MpobNCKQCfffvmB23LbcLxfGFtx2eVwvxC
wZIAoNxo4Tz9qkbQum5t7fPD2a2l3UPY
=elyr
-----END PGP SIGNATURE-----
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
