Insecure default url_shortener_cache path

[orlitzky]

So while reading issue #6, I noticed that the current default cache location is under /tmp, but with a fixed filename:

url_shortener_cache /tmp/DecodeShortURLs.sq3

This is vulnerable to a bunch of bad stuff, because /tmp is world-writable. For example, when the machine boots, anyone can create /tmp/DecodeShortURLs.sq3 as a symlink to something important that might later be clobbered by cache data. Or, for another example, anyone can create an empty file /tmp/DecodeShortURLs.sq3 before SpamAssassin does, and then later inject data into that file that SA will try to process.

There are more intricate attacks, of course -- it's better to avoid using /tmp entirely, if possible. Or if you'd like to default to a file in /tmp, use a "secure" filename that isn't known beforehand. I know nothing of Perl, but I'd bet File::Temp can do it. The downside to that is that the cache won't persist across reboots, so maybe it would help to include some instructions on where to put the cache permanently? Does SA have it's own secure temporary location?

[cepheid666]

An external call to mktemp could work, too. As you say, the downside is the file doesn't persist across restarts of SA. SA is typically rebooted every time there is a channel rule update, and some sysadmins may reboot it daily (or more often) for other reasons. So, having the file persist would be preferable, of course.

For single-user operation where SA is always run as a particular user, whether from spamd or the SA perl script, then it would be sufficient to create a directory solely available to that user (e.g., /home/spamassassin) with chmod 700, then place the DB there. Even with a fixed filename, it would be effectively secure, especially if the filename were changed from the default.

This could/should be placed in the README/instructions.

Of course, for single-user operation as above, issue #6 isn't an issue, since that only manifests with per-user operation.

For per-user operation, if point 2 in issue #6 is fixed, this issue becomes moot by default, assuming the default ("global" user) location is either disabled or similarly secured. For per-user ops, the DBs should be stored in user directories. If stored in $HOME/.spamassassin, that should always be chmod 700 anyway. For user "nobody" the DB could simply be omitted since spamd only runs as "nobody" when invoked by root, which would presumably not be that often in a per-user setup. For user "root" (when the SA perl script is manually run by root), the DB could be stored in /root (or whatever is used as root home) or in the main SA config directory (/etc/mail/spamassassin on my system). Either way, all DBs would be locked down if DSU could be made to work in a per-user way.

[orlitzky]

It looks like most other plugins (Bayes, TxRep, Hashcash,...) are using a file in userstate_dir, which defaults to ~/.spamassassin in SpamAssassin.pm. In that same file, the sub get_and_create_userstate_dir creates the userstate_dir as mode 700, so long as $use_user_pref is nonzero in sub init.

If those things happen by default, it might be safe to use $userstate_dir/DecodeShortURLs.sq3 as the cache? If not, then ~/.spamassassin/DecodeShortURLs.sq3 is at least a viable suggestion.

[cepheid666]

It looks like there are other calls to get_and_create_userstate_dir elsewhere, and I think it's pretty safe to assume that in a per-user setup, userstate_dir will exist. So using that directory should be the right answer. So implementing a default of __userstate__/DSU.sq3 should be the right answer. Now just have to figure out exactly how/where to do that. =)

[orlitzky]

Two single-user data points: on our mail server, if I delete /var/amavis/.spamassassin and restart amavis, the directory reappears with mode 0700. On the other hand if I start spamd, I don't see anything in /home/spamd.

[cepheid666]

If amavis is your SA glue then likely spamd is running as user amavis, is my guess.

[orlitzky]

In this case I checked to make sure that spamd was run with --username=spamd --groupname=spamd, and I also double-checked that the homedir for the spamd user is /home/spamd. I don't typically use spamd, though, so pretty much anyone else would be more qualified to evaluate that use case =)