You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by "Dan Mahoney, System Admin" <da...@prime.gushi.org> on 2005/08/20 06:05:36 UTC
protecting SQL login info
Hey all,
I'm doing everything (bayes, AWL, userprefs) in SQL. Is there some way to
protect the values I've got in /etc/mail/spamassassin/local.cf such as my
mysql username and password from casual snoopage?
Only think I could think of was to make SA setGID, and have the file chmod
750.
Any better ideas?
-Dan
--
<Belldandy> ha. you have not met me.
<BaldDwarf> ha. but i have sene pictures
<Belldandy> thanks but uh.,
<BaldDwarf> seen dammit! SEEN!
<Gushi> I don't know who dammit! is.
<Belldandy> so anyway
-Undernet #reboot, October 2nd, 2000, 3AM
--------Dan Mahoney--------
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
Site: http://www.gushi.org
---------------------------
Re: protecting SQL login info
Posted by "Dan Mahoney, System Admin" <da...@prime.gushi.org>.
On Tue, 6 Sep 2005, Michael Parker wrote:
> Dan Mahoney, System Admin wrote:
>
>>
>> With spamc/spamd this is not a problem, as spamd runs on a machine
>> that the shell users don't have access to (and reads the SQL login as
>> root before dropping its privileges).
>>
>> However, for sa_learn, and things like spamassassin -r (which
>> essentially is the same as sa-learn), they need to write to AWL/Bayes
>> -- and since they run as the user, they need to be able to read/write
>> the SQL login info even while running as that user.
>>
>
> SA 3.1 lets you move this functionality to spamd as well.
which means what, the user would have to call a spamc string like this?
| /usr/local/bin/spamc -d quark.gushi.org -S -u user@myhostname -r
** Spamd needs a config file, preferably with a setGID startup so only
spamd can read it.
** Spamd also needs a list of "trusted users" who can call it with -u, so
not just any jerk can poison my bayes tables.
** Spamd also needs an option to include a hostname in the username it
sends to spamassassin, either in the config file, or overridden on the
command line (possibly only by trusted_users).
For speed, any of the about COULD be compile-time options.
Are any of these ideas in the queue?
-Dan
--
--------Dan Mahoney--------
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
Site: http://www.gushi.org
---------------------------
Re: protecting SQL login info
Posted by Michael Parker <pa...@pobox.com>.
Dan Mahoney, System Admin wrote:
>
> With spamc/spamd this is not a problem, as spamd runs on a machine
> that the shell users don't have access to (and reads the SQL login as
> root before dropping its privileges).
>
> However, for sa_learn, and things like spamassassin -r (which
> essentially is the same as sa-learn), they need to write to AWL/Bayes
> -- and since they run as the user, they need to be able to read/write
> the SQL login info even while running as that user.
>
SA 3.1 lets you move this functionality to spamd as well.
Michael
Re: protecting SQL login info
Posted by "Dan Mahoney, System Admin" <da...@prime.gushi.org>.
On Tue, 6 Sep 2005, Eric W. Bates wrote:
> This is perhaps a little elaborate; and I have not tried to hook this
> into SA; but we are quite happy with a little bit of misdirection we use
> for the tools we have reading/writing to the SQL.
>
> There is a specified directory (call it dbpasswords). In the directory
> there is a file for each login. The file is named with the user's login
> name. The contents of the file is the password. The file is owned by
> the user in question with perms 400.
>
> Subsequently we overload/patch any code that needs a login (e.g.
> Class::DBI::mysql::set_db()) such that the EUID is used in getpwent to
> get the username, and thereby the password.
>
> This way, no passwords are ever embedded in any code or config files and
> there is one single location to change when the passwords are updated.
> This does require that the username used on the system is the same as
> the username for SQL. We frequently use suid to change the EUID of the
> web server to something with special access in the SQL (e.g. dbwriter).
> This special user usually has even lower permission level than the web
> server; with the exception of SQL access.
>
> We use this technique for CGI, mod_perl, php, etc. I have not examined
> SA 3 for use of this trick; but we are going try sometime soon.
No, there's one single user for ALL the database access. Spamd doesn't
support per-user SQL logins and passwords.
With spamc/spamd this is not a problem, as spamd runs on a machine that
the shell users don't have access to (and reads the SQL login as root
before dropping its privileges).
However, for sa_learn, and things like spamassassin -r (which essentially
is the same as sa-learn), they need to write to AWL/Bayes -- and since
they run as the user, they need to be able to read/write the SQL login
info even while running as that user.
However, if *they* can read it there's nothing stopping a malicious user
from just logging in and deleting all the table data (said user needs the
delete privilege...they may not be able to drop the tables if I revoke the
"drop" priv, but they can still delete all the data)
-Dan
>
> Dan Mahoney, System Admin wrote:
>> Hey all,
>>
>> I'm doing everything (bayes, AWL, userprefs) in SQL. Is there some way
>> to protect the values I've got in /etc/mail/spamassassin/local.cf such
>> as my mysql username and password from casual snoopage?
>>
>> Only think I could think of was to make SA setGID, and have the file
>> chmod 750.
>>
>> Any better ideas?
>>
>> -Dan
>>
>> --
>>
>> <Belldandy> ha. you have not met me.
>> <BaldDwarf> ha. but i have sene pictures
>> <Belldandy> thanks but uh.,
>> <BaldDwarf> seen dammit! SEEN!
>> <Gushi> I don't know who dammit! is.
>> <Belldandy> so anyway
>>
>> -Undernet #reboot, October 2nd, 2000, 3AM
>>
>> --------Dan Mahoney--------
>> Techie, Sysadmin, WebGeek
>> Gushi on efnet/undernet IRC
>> ICQ: 13735144 AIM: LarpGM
>> Site: http://www.gushi.org
>> ---------------------------
>
> --
> Eric W. Bates
> ericx@vineyard.net
> ------------ Output from gpg ------------
> gpg: WARNING: using insecure memory!
> gpg: please see http://www.gnupg.org/faq.html for more information
> gpg: Signature made Tue Sep 6 12:53:56 2005 EDT using DSA key ID 34382E51
> gpg: Good signature from "Eric W. Bates <er...@vineyard.net>"
> gpg: aka "ericx <er...@vineyard.net>"
> gpg: aka "Eric W. Bates <er...@ericx.net>"
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg: There is no indication that the signature belongs to the owner.
> Primary key fingerprint: EC0E 0CA8 37C3 43D2 5E4C 5D40 0F5A E825 3438 2E51
>
>
--
"Station!"
-Bill & Ted's Bogus Journey
--------Dan Mahoney--------
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
Site: http://www.gushi.org
---------------------------