-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Paul Howarth wrote:
On Tue, 15 Jan 2008 14:53:18 -0500 Daniel J Walsh dwalsh@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@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@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.