Bug 3934 - allow safe use of spamd on a multiuser machine using UNIX domain sockets and setgid spamc
Summary: allow safe use of spamd on a multiuser machine using UNIX domain sockets and ...
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamc/spamd (show other bugs)
Version: 3.0.1
Hardware: Other other
: P5 normal
Target Milestone: Future
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on: 4153
Blocks:
  Show dependency tree
 
Reported: 2004-10-27 14:44 UTC by Justin Mason
Modified: 2006-10-19 06:43 UTC (History)
2 users (show)



Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description Justin Mason 2004-10-27 14:44:51 UTC
dean gaudet <dean-list-spamassassin-dev@arctic.org>:


i wasn't ever fond of spamd trusting the User supplied by spamc -- and 
while identd is an OK hack for folks who run spamd on a network, it seems 
overkill for someone running spamd on localhost only.  using unix domain 
sockets there are two ways to increase the paranoia -- one would be to 
pass credentials over the socket, the other is to use a setgid spamc and a 
group-restricted unix domain socket.  credential passing isn't easily 
portable, so being lazy i've been using setgid spamc.

in my setup i have group spamc, and the socket is in /var/run/spamd, and i 
set perms like so:

-r-xr-s--x  1 root spamc 22164 Oct 26 23:21 /usr/bin/spamc
drwxr-x---  2 root spamc  4096 Oct 26 23:22 /var/run/spamd
srw-rw-rw-  1 root root      0 Oct 26 23:22 /var/run/spamd/sock

i stick the sock in a subdirectory which is group protected for historical 
reasons ... it's more portable -- older unixen didn't respect unix domain 
socket permissions... and prior to SA 3.0.0 i would have had to patch 
spamd to get perms on the socket correct.

anyhow there's two more things to be done -- patch spamc to disable -u, 
and make it default to this socket (so my users don't need to know these 
details).

the patch i use is below, but i'd like to get something accepted upstream 
so that i could eventually use a pre-built .deb rather than building my 
own.  the only part which needs generalizing is setting the default 
transport ... i suppose a config file or shell wrapper would solve it.  
(i don't like the shell wrapper because it messes with pre-packaged SA.)

suggestions?

-dean

--- spamassassin-3.0.1/spamc/spamc.c.orig	2004-10-22 18:39:18.000000000 -0700
+++ spamassassin-3.0.1/spamc/spamc.c	2004-10-27 11:53:58.000000000 -0700
@@ -277,6 +277,10 @@
             }
             case 'u':
             {
+		if (getuid() && getgid() != getegid()) {
+		    printf("you are running setgid, and -u is permitted only when root\n");
+		    ret = EX_USAGE;
+		}
                 *username = optarg;
                 break;
             }
--- spamassassin-3.0.1/spamc/libspamc.c.orig	2004-10-22 18:39:18.000000000 -0700
+++ spamassassin-3.0.1/spamc/libspamc.c	2004-10-27 11:53:58.000000000 -0700
@@ -1124,8 +1124,13 @@
 
     memset(tp, 0, sizeof *tp);
 
+#if 0
     tp->type = TRANSPORT_LOCALHOST;
     tp->port = 783;
+#else
+    tp->type       = TRANSPORT_UNIX;
+    tp->socketpath = "/var/run/spamd/sock";
+#endif
     tp->flags = 0;
 }
 


later: 


On Wed, 27 Oct 2004, Justin Mason wrote:

> Both will break existing usage at other sites; some thought for backwards
> compatibility is required before we could apply those to the distribution.
> In particular, defaulting to only allowing -u for root would break
> a *lot* of existing users running spamc from the MTA.

i think the setgid portion is backward compatible -- it only restricts -u 
to root when the executable is installed setgid.  otherwise it allows -u 
just fine... i'm guessing very few folks use a setgid spamc, but let me 
know.

as for the default transport -- i just figured out a local solution 
that'll work with pre-packaged SA, so it's no biggie (which is good, i 
didn't feel like writing config file parsing code :)

-dean



My opinion: this is cropping up on Red Hat's bugzilla as well, at
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136367 .   Well worth
fixing.   I think dean's point is worthwhile -- the -u restriction only takes
effect if spamc is setgid, and it will never be setgid unless something like
this is what the developer had in mind, anyway.  so this may be a good solution...
Comment 1 Daniel Quinlan 2005-04-12 14:45:58 UTC
Justin?

I'd apply this except for your concern.  3.1.0 is the right place if
we are going to make this change.
Comment 2 Justin Mason 2005-04-12 15:13:56 UTC
+1 on the setgid change, once it's accompanied by some documentation in spamc.pod.

-1 on the changing the default to use a UNIX domain socket instead of TCP,
however; changing the defaults is not a good way to deal with Dean's problem, it
works for him but will break virtually everyone else ;)

instead we should come up with a way for spamc to have a configuration file of
systemwide defaults (/etc/mail/spamassassin/spamc.conf), so people who want to
allow users to not have to remember what options to use can just set them once
in that file.

BTW regarding the setgid change: it may be better to accompany that with a new
option which *disables* that new paranoia, just in case.  For example, what if I
have my MTA running as uid="mymta", delivering using "spamc -u jm", with a
hidden UNIX-domain socket as Dean describes?  it won't work, because this patch
only allows -u+setgid if spamc is running as root.  there's a possibility there
are people out there using something like that, and we just don't know it; if we
break this use case we should provide a way to fix it again.
Comment 3 John Madden 2005-04-13 05:58:32 UTC
(In reply to comment #2)
> instead we should come up with a way for spamc to have a configuration file of
> systemwide defaults (/etc/mail/spamassassin/spamc.conf), so people who want to
> allow users to not have to remember what options to use can just set them once
> in that file.
> 
Bug 4153 has my initial attempts at a patch to have a global spamc.conf file for
just this reason.

The CLA went in the post about a month ago.
Comment 4 Justin Mason 2005-04-13 10:10:24 UTC
thanks John -- I think that's a better solution alright.
Comment 5 Daniel Quinlan 2005-04-30 21:00:49 UTC
punting to 3.2.0
Comment 6 Justin Mason 2005-05-11 20:12:31 UTC
bug 4153 is now applied.
Comment 7 Justin Mason 2006-04-21 18:06:04 UTC
ping: this needs work if it's to get into 3.2.0.
Comment 8 Justin Mason 2006-10-19 06:43:02 UTC
no motion: moving off 3.2.0