Bug 136367

It is far too late to add a new perl module for this for FC3 or RHEL4,
unless this turns into a huge security debacle.  Why didn't you
mention this earlier? =)

Thoughts Mark or Josh?

Guess this is my fault, I tried to avoid spamd/spamc but when I found
that Ximian Evolution silently starts a publically accessible spamd I
started investigating.

Maybe you could make an exception as this perl module consists of a
single file only. Additionally the dependency has been there for a
long time but silently ignored.

I don't know how you define 'huge security debacle' but I am not
comfortable with a daemon that impersonates any user read from an
untrusted network connection and performs rather complex actions
including creating and altering configuration files.

While it'd be nice to do something about this, I don't think it should
be considered a blocker for the FC3 release (but maybe RHEL4).

Reasons:

0) The ident thing is somewhat complex, in that not only do the issues
mentioned above need to be solved, but there needs to be some checks
to make sure that a local identd is actually running and configured
properly. It's not necessarily a gigantic chore, but there's some
design work involved that shouldn't be rushed at the last minute.

1) It's a network connection, but bound only to localhost by default,
and unless someone changes that or changes the default source route
verification policy in /etc/sysctl.conf, it's only accessible from the
local machine.

2) SpamAssassin is _designed_ to deal with arbitrary input from
expected to be malicious sources -- spammers. The ability to run using
someone else's config and bayesian database is way not cool, but any
bug which would let it go further than that would likely be
exploitable remotely in other ways too. If we trust spamassassin at
all, we implicitly are trusting it in this case anyway.

I am wary of anything that relies upon something as bad as ident, or
necessitates that identd is installed and enabled.  I wish there were
a better way.

I need to consult others within RH before enabling this.

I fail to see why Evolution has to run spamd.  IIRC spamc looks like
the spamassassin executable, and a speedup is the only real advantage.
 It seems obvious to me to just have Evolution use the spamassassin
executable rather than trying to fix spamd.

The spamd README speaks of the ability to spoof the user running
spamc, so this is a known issue, yet they've not made an effort to fix
it, which leads me to believe it's not a simple fix, and ident isn't
the ideal fix.

Josh -- the speedup is incredibly substantial. One user's e-mail is
enough to overstress a medium-powered PC with just running
spamassassin directly. A single user with a low volume of mail on a
fast system might be fine, but....

It seems like a cookie-based approach would work. (Especially for
local use.) I should take this up with the upstream developers.

upstream developer here:

1. spamd can be run as non-root, no problem

2. a cookie-based approach would work; definitely worth opening an
upstream bug about (and possibly providing a patch ;)

While identd may be reasonably truthful to localhost, I am further
unwilling to rely on identd because you cannot rely on it to be
truthful over the network.  spamc and spamd are intended to be used
either locally on the same system, or in a distributed manner.  This
only slightly raises the bar of abuse, and potentially lull the admin
into a false sense of security.

We will not accept an ident based approach.  Please think of another way.

@#3/2: Exploiting the account of a user running spamassassin is one
thing, beeing able to exploit the account of any user on a system
runningt spamd is much more severe.

@#5: I agree with this, either all applications or the spamc
executable should be altered to try spamd and fall back to
spamassassin if that fails.

#6: sacrificing security for speedup is the trademark of a big two
letter company, isn't it?

@#8/1: this would mean to 1) have no or a world-readable per-user
configuration, including the personal whitelist 2) have no or a world
modifiable bayes database

hmm. here's a better option: use unix-domain sockets instead of TCP/IP
sockets, and maintain the sock in a mode 700 subdir of ~.

Justin -- that works for the instance spawned by Evolution. What to do
about the /etc/init.d/spamassassin one?

hmm.   true.  I suspect the only solution there is some kind of
shared-secret cookie-based handshake, again.

We could have spamd listening on a mode 0660 or 0600 socket with a
setuid or setgid spamc executable.

folks -- opened an upstream bug about the setgid spamc idea here: 
http://bugzilla.spamassassin.org/show_bug.cgi?id=3934  -- another user
cropped up on the list with similar thinking.

Eh?  setgid spamc seems like almost an even worse solution unless I'm
really misunderstanding.  This does nothing to secure network
spamc/spamd authentication, and is it a good idea to diverge?  Also
does this work on all platforms supported by spamassassin?

Warren -- could you post that on the upstream BZ instead/as well?  I'd
prefer to avoid two parallel discussions.

you're right, it doesn't do anything useful for network spamd/spamc,
just localhost.  but this report seems to be about the localhost case
only, AFAICS.

I'm planning not to diverge.  hence upstream ;)

As far as I can think, there's no good way whatsoever (short of
passing around keys) to securely use spamd over the network. So I
propose not even worrying about that case. :)