package: spamassassin
version: 3.1.7

Helllo,

if not changed by hand, spamd will be running as root in default installation.
This can be changed by editing  /etc/default/spamassassin by hand.
Change:
OPTIONS="--create-prefs --max-children 5 --helper-home-dir"
to:
OPTIONS="--create-prefs --max-children 5 --helper-home-dir -u Debian-exim -g
Debian-exim"
If using exim.
Imho this default is risky since spamd handels untrusted data and
MTA-User-privileges ought to be sufficient in many common cases ...

Keep smiling
yanosz

In order for user preferences and Bayesian scoring to work, spamd needs
to be able to 'su' to the identity of the mail recipient. This is
something most people expect to work by default, so spamd runs as root
by defaulṫ.

A newer version of spamassassin (3.3.2-3, probably) will introduce a
debian-spamd user, and it's safe to run spamd as that user if desired.

noah

Control: severity -1 serious
Control: tags -1 security
as root is bad for the security. The issue is that several users (including me) have
complained that spamassassin touches the root account.

A recall (a part of) the issue:

Jun 11 11:48:58 joooj spamd[197569]: check: dns_block_rule RCVD_IN_VALIDITY_CERTIFIED_BLOCKED hit, creating /root/.spamassassin/dnsblock_sa-trusted.bondedsender.org (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny sa-trusted.bondedsender.org" to disable queries)
Jun 11 11:48:58 joooj spamd[197569]: check: dns_block_rule RCVD_IN_VALIDITY_RPBL_BLOCKED hit, creating /root/.spamassassin/dnsblock_bl.score.senderscore.com (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny bl.score.senderscore.com" to disable queries)
Jun 11 11:48:58 joooj spamd[197569]: check: dns_block_rule RCVD_IN_VALIDITY_SAFE_BLOCKED hit, creating /root/.spamassassin/dnsblock_sa-accredit.habeas.com (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny sa-accredit.habeas.com" to disable queries)

I forgot: this is on a Debian/stable machine (Debian 12 bookworm).

Control: severity -1 wishlist

There's a difference between running spamassassin as root versus running
spamd as root.  Spamd runs as root so that it can setuid to the
individual users receiving the incoming mail.  This is necessary in
order to support per-user configuration, bayes databases, etc. in
~/.spamassassin.

Quoting spamd's upstream documentation,

        When run as root, spamd will change uid's to the user invoking
        spamc in order to read and write to their configurations. This
        functionality is not possible if spamd does not run as root and is
        a disadvantage if you rely on this. If you use mysql or LDAP for
        per-user configuration there is no reason in the world to run as
        root, and this remains fully functional.

See more at https://svn.apache.org/repos/asf/spamassassin/trunk/spamd/README

In some sites, it may make sense to use the alternate configuration
described there, but that's a more involved setup and not something that
we're going to make the default.  Thus my reduction of the severity here.

Running spamassassin itself, which is the part that actually processes
inbound mail, as root would indeed be a bad idea.  But that doesn't happen
by default.

noah

It creates files in the root account, so this is clearly broken!

Are you doing mail delivery as root, or is this something that's
happening before setuid() to some other account?  If the latter, then
yes, something is clearly broken.

I see that you've raised the issue on a couple of different mailing
lists.  If spamd is creating files in (or otherwise touching) the user
preferences directory before calling setuid() to process an inbound
message, then this seems like a distinct bug that should be reported
upstream.

noah

To my personal account, via procmail in my personal account:

  :0 fw: .spamassassin.lock
  | spamc -t 240 -s 3000000

This issue has been reported by several users upstream. This is not
specific to me.

Note that there are actually 2 issues I reported:

1. The fact that spamassassin still does Validity queries *by default*.

2. When spamassassin does a Validity query and this is blocked,
   it creates files in the root account.

Some user has "spamd child" processes as spamd user. But in Debian,
they are root. Perhaps this is the issue?

However, I don't know the expected intent of these files.

Most of the VALIDITY rules have a score of 0, which disables the lookup
altogether.  However, even the latest
/var/lib/spamassassin/4.000002/updates_spamassassin_org/72_scores.cf
contains a nonzero score for some of them:

$ grep -F RCVD_IN_VALIDITY /var/lib/spamassassin/4.000002/updates_spamassassin_org/72_scores.cf
score RCVD_IN_VALIDITY_CERTIFIED_BLOCKED    0.001 0.001 0.001 0.001
score RCVD_IN_VALIDITY_RPBL_BLOCKED         0.001 0.001 0.001 0.001
score RCVD_IN_VALIDITY_SAFE_BLOCKED         0.001 0.001 0.001 0.001

So those will still trigger DNS lookups.  Upstream set a zero score for
most of the Validity rules in
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8278, but I think
they probably should have updated these, too.

Yes, this seems like a bug.  But I don't think it reflects a bug in the
default configuration, but rather an upstream code issue.  Spamd should
not be accessing the user prefs directory before changing user IDs.

No, those root processes are just pre-spawned workers. They're the ones
expected to setuid() to the recipient when processing mail.

noah

See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425684 from
way back in 2007.  Spamassassin has been doing this sort of thing for a
while.  It may be better to move future discussion on this particular
issue to that bug.

I'd be curious about what happens on your system with the following in
place:

# /etc/systemd/system/spamd.service.d/override.conf
[Service]
ReadOnlyPaths=/root

I'm running with that configuration right now, and have not experienced
any issues.  If anything does fail, I'm hoping that the logs will be
educational.

noah

# systemctl daemon-reload
# systemctl restart spamd.service

Indeed, this solved the issue about the root account:
I now get

Jun 12 23:41:39 joooj spamd[232280]: check: dns_block_rule RCVD_IN_VALIDITY_RPBL_BLOCKED hit, creating /var/lib/spamassassin/dnsblock_bl.score.senderscore.com (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny bl.score.senderscore.com" to disable queries)
Jun 12 23:41:39 joooj spamd[232280]: check: dns_block_rule RCVD_IN_VALIDITY_CERTIFIED_BLOCKED hit, creating /var/lib/spamassassin/dnsblock_sa-trusted.bondedsender.org (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny sa-trusted.bondedsender.org" to disable queries)
Jun 12 23:41:39 joooj spamd[232280]: check: dns_block_rule RCVD_IN_VALIDITY_SAFE_BLOCKED hit, creating /var/lib/spamassassin/dnsblock_sa-accredit.habeas.com (This means DNSBL blocked you due to too many queries. Set all affected rules score to 0, or use "dns_query_restriction deny sa-accredit.habeas.com" to disable queries)