G.Wolfe Woodbury wrote:
Paul Howarth wrote:
On Wed, 18 Feb 2009 17:53:41 -0500
"G.Wolfe Woodbury" <ggw@xxxxxxxxxxxxxxxxxxx> wrote:
Similar to the mailman problem, SELinux doesn't understand the
interactions between sendmail and spamassassin. In this case,
however, the spamassassin stuff quits working completely.
This installation of spamassassin uses the "spamc" daemon, and mails
are passed to that daemon from user's .procmailrc files. (This allows
the user to opt-in/opt-out of spam detection on their own by altering
their own .procmailrc file.)
SELinux complains a lot because every message passwd from the user
delivery chain gets a denial because "sendmail" (actually procmail)
has no permissions to write the spamassassin spamc socket:
type=AVC msg=audit(1234094494.975:3163): avc: denied { read write }
for pid=612 comm="spamc" path="socket:[2166561]" dev=sockfs
ino=2166561 scontext=system_u:system_r:spamc_t:s0
context=system_u:system_r:sendmail_t:s0
tclass=unix_stream_socket
This is actually spamc failing to read/write a sendmail socket and is
most likely to be a leaked file descriptor in the sendmail local
delivery process, as per Bug #485426. Do you have *any* milters in your
sendmail config?
Well, there is a clamav-milter in place to check incoming mail for
viruses as some users read mail via OE and Windows Thunderbird. This
has never been a problem on this system.
My point is that spamc is doing operations in a sendmail context because
sendmail is calling procmail to do local delivery and the first entry in
most user .procmailrc filter lists is a pipe to/from spamc. The context
is two execs removed from sendmail itself. The policy simply doesn't
recognize that a sendmail context is calling spamc several hundred times
a day.
I disagree; the AVC above shows a process running in spamc_t failing to
read/write a socket that's sendmail_t. So sendmail will have
transitioned via procmail_t in the local delivery process and then on to
spamc_t from there. I believe that these denials are from a leaked
socket descriptor that sendmail uses to communicate with clamav-milter,
and I don't think these are the cause of the problem you're getting in
enforcing mode. You could test this theory by briefly disabling
sendmail's use of clamav-milter and seeing if the AVCs appear next time
mail comes in.
I don't fully understand some of the concepts used in SELinux, and am
running F10+updates in "permissive" mode so that things work but I
get notified of "abnormal" events.
Additionally, other aspects of the sendmail/spamassassin interaction
attract SELinux complaints. (getattr of spamc socket, etc) but I geet
thousands of complaints about the read/write of the spamc socket.
(about 8 active e-mail accounts, several of which are spam traps.)
Thanks for your attention and patience.
Can you post examples of the other denials you get?
Paul.
On closer examination, there are no other spamassassin/sendmail AVCs.
I have a few clamav-sendmail context AVCs, but that are 6 a day vs. 1200
a day for the spamc AVCs.
Actually reading through the selinux trapper messages is making some
things clearer. I'm now more convinced that this is a policy issue
rather than a bug.
If things break when you're in enforcing mode and you're not doing
something very unusual or silly (which doesn't seem to be the case),
then yes, that'll be a policy bug.
If you can test whether my theory about the leaked file descriptors is
right, and it shows that I am, you could use a local policy module to
make those AVCs go away and then it might be easier to spot the problem
that's actually breaking things for you in enforcing mode.
Paul.
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
