Bug 136367 - spamd should use --auth-ident to verify local users
spamd should use --auth-ident to verify local users
Product: Fedora
Classification: Fedora
Component: spamassassin (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Chip Turner
: Security
Depends On: 136392
  Show dependency treegraph
Reported: 2004-10-19 11:45 EDT by Matthew Miller
Modified: 2007-11-30 17:10 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-11-16 16:13:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Matthew Miller 2004-10-19 11:45:50 EDT
The man page for spamd says "the default behaviour is to setuid() to
the user running "spamc", if "spamd" is running as root.
Unfortunately, this appears to be largly optimism -- what the code
appears to actually do is run as whatever the user connecting over the
network *says* is their username.

The impact is that local users (spamd does default to only listening
on could cause spamd to run as other users -- reading their
config files and possibly messing up their bayesian training. Or if
there's a loophole in the code, doing something worse.

There is a --auth-ident flag which causes spamassassin to use ident to
verify the user account passed from spamc. Since it's on the local
host, presumably our own identd can be trusted.

We'd need to provide the required Net::Ident perl module as well. And,
as I understand it, the local identd would need to return valid
unencrypted usernames to queries from localhost -- that might be a
Comment 1 Warren Togami 2004-10-19 17:45:25 EDT
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?
Comment 2 Thomas Zehetbauer 2004-10-20 06:32:07 EDT
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.
Comment 3 Matthew Miller 2004-10-21 09:56:53 EDT
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).


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.
Comment 4 Warren Togami 2004-10-22 08:45:55 EDT
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.
Comment 5 Josh Bressers 2004-10-22 09:14:31 EDT
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.
Comment 6 Matthew Miller 2004-10-22 09:23:50 EDT
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....
Comment 7 Matthew Miller 2004-10-22 10:58:01 EDT
It seems like a cookie-based approach would work. (Especially for
local use.) I should take this up with the upstream developers.
Comment 8 Justin Mason 2004-10-22 12:41:06 EDT
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 ;)
Comment 9 Warren Togami 2004-10-25 03:47:59 EDT
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.
Comment 10 Thomas Zehetbauer 2004-10-25 19:19:00 EDT
@#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
Comment 11 Justin Mason 2004-10-27 15:34:11 EDT
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 ~.
Comment 12 Matthew Miller 2004-10-27 15:47:26 EDT
Justin -- that works for the instance spawned by Evolution. What to do
about the /etc/init.d/spamassassin one?
Comment 13 Justin Mason 2004-10-27 15:58:09 EDT
hmm.   true.  I suspect the only solution there is some kind of
shared-secret cookie-based handshake, again.
Comment 14 Thomas Zehetbauer 2004-10-27 16:01:07 EDT
We could have spamd listening on a mode 0660 or 0600 socket with a
setuid or setgid spamc executable.
Comment 15 Justin Mason 2004-10-27 17:41:45 EDT
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.
Comment 16 Warren Togami 2004-10-27 22:10:30 EDT
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?
Comment 17 Justin Mason 2004-10-28 13:51:56 EDT
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 ;)
Comment 18 Matthew Miller 2004-10-28 13:55:57 EDT
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. :)

Note You need to log in before you can comment on or make changes to this bug.