On Fri, 2014-05-23 at 15:09 -0700, Ian Zimmerman wrote:
> On Fri, 23 May 2014 20:35:26 +0200 Karsten Bräckelmann wrote:
> Karsten> That means you have been running lint check as a user, who is
> Karsten> not the user receiving mail. Linting also checks user_prefs,
> Karsten> but for obvious reasons only for the current user.
>
> I mostly get the rest of your answer, but this is incorrect. Same user,
> I'm 100% sure. Unless you count spamd checking on my behalf as
> different user - do you?
Yes.
user_prefs are per user. They are read by the spamd child process for
each and every message processed. If the spamd daemon runs as root, the
children setuid to the spamc calling user (or given -u argument), to
determine which user_prefs to use. In your case the spamd master process
already runs as user spamd and the setuid step is omitted. The
user_prefs are still based upon the user the spamd child runs as.
Look at it this way: Both the spamd master process as well as its
children are running as an unprivileged, dedicated user. You don't
expect that user to have access to your actual mail receiving account,
do you?
My wording of "user receiving mail" should have been "processing user".
I was a little sloppy, because your OP did not mention spamd. Given
details are "my user_prefs", logs showing a "user" named user, and
mentioning spamc being called via procmail.
> Karsten> (FWIW, what really would be disappointing is allowing users to
> Karsten> inject code into the daemon. Which loadplugin in user_prefs
> Karsten> would be.)
>
> I assumed spamd forked to process each request, and loaded the plugins
> only in the child.
That is basically correct -- with a notable exception of no plugins
being loaded. ;)
The forking (and setuid) are insufficient to protect the server from
malicious users DDoS'ing the server, if the user is allowed to run
arbitrary code (which a user provided plugin is). By default user_prefs
are not even allowed to contain rules, for that same reason with less
severe possible impact.
In your case of a dedicated spamd user, an attacker able to load a
plugin even potentially can access *any* other user's mail while being
processed by SA.
Again, see the Administrator Settings section in M::SA::Conf.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
