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