Um... Am I missing something here? I have spamc and spamd running on the same box. Spamd only listens to 127.0.0.1.
Why do we need to authenticate the user of spamc at all? Are we worried about a remote user running spamc on their box and forging mail through ours? A local user forging something through our box? If we use localhost, packet sniffing is impossible, right? I'm sorry if I'm being stupid, but the light bulb hasn't turned on for me yet. Thanx! -Michael >>> Bart Schaefer <[EMAIL PROTECTED]> 11/14/02 10:19AM >>> On Wed, 30 Oct 2002, Michael Stenner wrote: > This is all great, but we're a little concerned about the fact that a > modified spamc can be used to do mildly nasty things to other people > by telling spamd it's someone else. On Thu, 14 Nov 2002, Theo Van Dinter wrote: > I still don't see the purpose of authentication in spamd. Unless you > enable user rules, the only things I can think of that could happen > maliciously is tainting the AWL and generating lots of log entries with > the other user's name. Wouldn't it be sufficient to require that spamc (as well as spamd) be able to setuid successfully or else ignore the -u option? Then the -u option is usable only e.g. in /etc/procmailrc before DROPPRIVS, and anyone who wants to be malicious also has to be privileged enough that the -u option makes no difference. Do it like this: (1) Require the existence of a special pseudo-user to which spamc must setuid before it will pass the -u username to spamd. (-U option?) (2) Have spamc read a password from a file whose permissions must be set such that only that uid can read it. That password is sent along with the username, and must match a password in another file readable only by the user under which spamd starts (before setuid), e.g. root. Add salt as required to prevent packet sniffing. The password is just to prevent somebody from hacking their own copy of spamc to skip the setuid step. As a third option, the password could enable allow_user_rules, but if it were not provided spamd would proceed anyway, without user rules. This won't interfere with "personal" installations of spamassassin, because in that case both spamc and spamd must (almost by definition) already be running as the correct user. Or, require a compile-time choice of "not quite so insecure mode" to use this mechanism. ------------------------------------------------------- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk ------------------------------------------------------- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
