Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 91430 - spamassassin insecure file permission
Summary: spamassassin insecure file permission
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Default Configs (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Gentoo Security
URL:
Whiteboard: jaervosz
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-04 06:38 UTC by Romang
Modified: 2006-02-21 04:27 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Romang 2005-05-04 06:38:29 UTC
spamassassin file /etc/mail/spamassassin/local.cf could contain sensitive informations like mysql login and password

This file shouldn't be readable by others.
Maybe affect the functionnality off the software.



Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Actual Results:  
/etc/mail/spamassassin/local.cf is readable by all

Expected Results:  
/etc/mail/spamassassin/local.cf shouldnt' readable by all

How to configure spamassassin with mysql login and password

(Tell Spamassissin to use MySQL for bayes data
bayes_store_module              Mail::SpamAssassin::BayesStore::SQL
bayes_sql_dsn                   DBI:mysql:sa_bayes:localhost:3306
bayes_sql_username              db_name
bayes_sql_password              another_very_secret_password

(Tell Spamassissin to use MySQL for AWL data
auto_whitelist_factory          Mail::SpamAssassin::SQLBasedAddrList
user_awl_dsn                    DBI:mysql:sa_bayes:localhost:3306
user_awl_sql_username           db_name
user_awl_sql_password           another_very_secret_password
Comment 1 Michael Cummings (RETIRED) gentoo-dev 2005-05-04 07:28:56 UTC
Although I can see the potential of the issue - isn't that file read when a user self-invokes spamassassin (procmail, sa-learn, what have you)? I would think that <user> needs to be able to read the file as well - tightening the permissions would then vary on deployment intentions. If you mail server is configured to be the only thing ever invoking SA, then only the mail server needs access to it, but if you are running a desktop environment with multiple users, each chosing to invoke SA at their own convenience, then that file would need to be readable by anyone.

In short, unless I'm off base, permissions on local.cf (or any other file in /etc/mail/spamassasin) need to be left at the discretion of the admin of the box, and may vary depending on implementations.

I could of course be completely wrong :)
Comment 2 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-05-04 08:54:30 UTC
Other option would be to tighten default permissions and let the admin loosen up if necessary?
Comment 3 Romang 2005-05-04 08:58:43 UTC
Hi,

if the login & password of amavisd.conf is readable by everybody,
then any local user (apache, or shell account) could have access to
all rules off a user and modified it.

here the right how should be granted on mysql to run amavisd with mysql :

mysql> create database dbname;
mysql> GRANT ALL PRIVILEGES ON dbname.* TO 'dbuser'@'localhost' IDENTIFIED BY 'anoter_very_secret_password';

For more informations :

http://www.gentoo.org/doc/en/mailfilter-guide.xml

Regards.
Comment 4 Michael Cummings (RETIRED) gentoo-dev 2005-05-04 09:11:16 UTC
Per a conversation on irc, i'd recommend putting a warning in the last steps of the ebuild to make the user aware. local.cf can be used for mysql storage, sure - but it can also just be used to setup global whitehole rules, or common mail header changes. I just need to verify that users are reading this file when they manually invoke sa - if they're not, and its only used by say spamd, then tightening the perms in the ebuild is fine. But if not, and it is used by average users, I don't think we should be introducing a new problem to users who just invoke it via their mail client (like kmail's tie in to sa). I think the short version of that is I'm favoring a fat warning about the perms for now :)
Comment 5 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-05-09 23:05:35 UTC
Micheal any news on this one?
Comment 6 Michael Cummings (RETIRED) gentoo-dev 2005-05-10 03:13:44 UTC
yeah - i dropped the ball on this (maybe i was hoping someone would post that was brighter than me? or at least more clued :) ). i'll mark this in my to-do list, sorry about that
Comment 7 Malte S. Stretz 2005-05-11 10:05:21 UTC
All files with the extension .cf in /etc/mail/spamassassin are read.  So a possible solution could be to add a boilerplate file, eg. secrets.cf, with the appropriate perms and add some comment to the top of local.cf that users should use that one for sensitive information.
Comment 8 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-07-16 01:54:31 UTC
Michael any news on this one? 
Comment 9 Michael Cummings (RETIRED) gentoo-dev 2005-08-16 02:52:38 UTC
In place addition of a secrets.cf and a note in local.cf recommending its use
(with appropriate permissions) for storing sensitive data.
Comment 10 Elfyn McBratney (beu) (RETIRED) gentoo-dev 2005-09-04 05:00:00 UTC
What's the status on this one - ready to go, or .. ? (:
Comment 11 Thierry Carrez (RETIRED) gentoo-dev 2005-09-04 11:37:38 UTC
In fact fix has been shipped, so we can close this one.
Comment 12 Roy Kidder 2006-02-01 17:55:13 UTC
Seems this fix causes sa-learn to generate an error when executed as a non-root user:

sa-learn --spam ~/.maildir/.Spam.Spam-learn/cur/
config: cannot open "/etc/mail/spamassassin/secrets.cf": Permission denied
Comment 13 Michael Cummings (RETIRED) gentoo-dev 2006-02-20 12:44:52 UTC
(In reply to comment #12)
> Seems this fix causes sa-learn to generate an error when executed as a non-root
> user:
> 
> sa-learn --spam ~/.maildir/.Spam.Spam-learn/cur/
> config: cannot open "/etc/mail/spamassassin/secrets.cf": Permission denied
> 
Read comment #9

closing bug gets +1 vote from me
Comment 14 Roy Kidder 2006-02-21 04:27:03 UTC
(In reply to comment #13)
> Read comment #9

I'm afraid I don't understand how comment #9 helps. When I run sa-learn as a normal user, it complains that it can't read secrets.cf. I understand that a normal user shouldn't see the contents of secrets.cf. What I don't understand is why sa-learn tries to access it and how I can get sa-learn to quit complaining. Any thoughts?