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.
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
