[wplug] SpamAssassin -- user_prefs security hole?

[Bill Moran]

James O'Kane wrote:
> On Wed, 26 May 2004, Bill Moran wrote:
> 
>>James O'Kane wrote:
>>
>>>You could start it as a different user, but the problem would be similar.
>>>Users could run arbitrary perl as the user that is running spamd.
>>
>>Whoah there!
>>
>>That problem is so _not_ similar, that it's actually accepted security
>>practice!
> 
> I agree running daemons as unique users is a good idea. I meant it would
> be similar in that you're allowing a user to run aribtrary code as another
> user. It's different from say, named, which often runs as a unique user.
> named can own files, and directories for example. If you enable this
> option in spamassassin, the user running the process cannot own any files
> or directories.
> 
> In theory, a user could write a spamming engine into a user_prefs files
> and instead of processing an incoming message for spam fingerprints, it
> uses the incoming message to send out 1000's of spams to other machines.
> Something like this could be more difficult to track down than just an
> open relay for example.
> 
> I've only known one person who ever wrote their own rules anyway, and he
> managed his own mail server so he could trust himself not to be malicious.
> It just seems overly complicated to secure, with minor benifits.
> 
> My opinions in summary:
> Running spamd as a unique user: GOOD
> Allowing users to create rules: BAD

I can't disagree with this.  In fact, I agree wholeheartedly.

If you're going to allow users to write their own spamd rules, you'll have to
apply the same security considerations as if you were letting them ssh in and
have a shell account.  While it's certainly possible to secure, it sure it a
lot of work.

-- 
Bill Moran
Potential Technologies
http://www.potentialtech.com