Ubuntu
spamassassin package

don't run as root by default

Bug #1442087 reported by Tim Kuijsten
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
spamassassin (Ubuntu)
Confirmed
Wishlist
Unassigned

Bug Description

I was surprised that after following https://help.ubuntu.com/14.04/serverguide/mail-filtering.html this leaves me with the spamassassin daemon running as root.

This is not of the same standard compared with the secure defaults that Postfix and Dovecot use. I think this undermines the whole setup and comes a bit unexpected. I would suggest to create a separate unprivileged user (maybe spamd?) for running spamd only and keep the user debian-spamd for updating the rules.

Revision history for this message
Andreas Olsson (andol) wrote :

One reason one might want to run spamd as root is that it allows spamc to be called by multiple users, and have spamd change uid accordingly. See /usr/share/doc/spamassassin/README.spamd.gz for further info

Changed in spamassassin (Ubuntu):
importance: Undecided → Wishlist
status: New → Confirmed
Revision history for this message
Tim Kuijsten (kuijsten) wrote :

This user switching is for reading per-user configurations only and I think can be mitigated by making the per-user config world readable.

Furthermore from the README.spamd.gz you've mentioned "If a fault is found in spamd or spamassassin code, any third party linked-libraries or imported perl modules there is the potential for abuse of both the running uid of spamd, and the uid of the username supplied by spamc (and this could be any user)."

I'm not sure how many LOC but there is quite a slew of extra code with all the plugins that ship with SA. I question if all this code is maintained with the same attention and security awareness as other parts of the mail stack. I know all other parts are not executed as root. Of course statistics wouldn't have hurt ;-).

Revision history for this message
Andreas Olsson (andol) wrote :

Well, the user switching can also apply to writing to user specific bayes databases, even if that too can be solved in other ways.

Anyway, I'm not in any position to make any decisions here, I just wanted to provide a bit of context while doing initial bug triage.

Revision history for this message
Tim Kuijsten (kuijsten) wrote :

Yes, thanks for the link and thoughts. I'm currently investigating if I can leave all the SA, amavis and clamav code out of my setup by using the blacklist feature of postscreen*.

* http://www.postfix.org/postconf.5.html#postscreen_dnsbl_sites

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.