On Thu, Nov 14, 2002 at 08:19:56AM -0800, Bart Schaefer wrote:
> 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.
As I understand it, your proposed method includes:
* having spamc be installed setuid and owned by this other user
* having a plaintext password on disk, readable only by this other
user
This way, spamc authenticates the user (because it knows who it's
invoked by) and then spamd authenticates spamc (because only the
system-wide setuid spamc could read the password).
Is that about right? I don't know. That seems considerably more
complex to me. I appreciate that it doesn't involve a third process
(ident) but it just feels a bit kludgey to me. I'd prefer to stay
away from setuid binaries if possible.
(My favorite method is still the UNIX sockets, but that will take more
work and I'm still looking into it.)
-Michael
--
Michael Stenner Office Phone: 919-660-2513
Duke University, Dept. of Physics [EMAIL PROTECTED]
Box 90305, Durham N.C. 27708-0305
-------------------------------------------------------
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
