Re: [exim-dev] Candidate patches for privilege escalation

Top Page
Delete this message
Reply to this message
Author: W B Hacker
Date:  
To: David Woodhouse
CC: Phil Pennock, exim-dev
Subject: Re: [exim-dev] Candidate patches for privilege escalation
David Woodhouse wrote:
> On Mon, 2010-12-13 at 18:01 -0500, Phil Pennock wrote:
>>
>> One of the installation modes for mailscanner is to make the spool
>> directory be a macro:
>>
>> http://wiki.mailscanner.info/doku.php?id=documentation:configuration:mta:exim:installation
>
> Wait a minute, wasn't that broken even *before* we started to further
> restrict the use of -C and -D?
>
> It says (near the end):
>
>     If there is any software running on the machine that generates email
>     that should be scanned (e.g. a webmail application) you can still use
>     this setup, but you must configure the application either to submit
>     email via SMTP, or to use the extra command-line options
>     -odq -DSPOOL=/var/spool/exim.in.

>
> But if the application gave -DSPOOL= on the command line, it wouldn't
> have been trusted. Exim would have dropped privileges to the *real*
> user, not to Exim. And thus wouldn't have been allowed to write to the
> spool.
>


.... all depending on the user and group membership of said 'real' user, AND
those of the spool.

Locally alterable, as in our practice w/r the 'postal' group.

Hence even testing 'vanilla' installs is at best indicative of devel *intent*,
not of real-world practice. Your arms reach only to the hands.

For the same reason, several of the restrictions presently in-work are not.
(restrictions).

Against gaining 'root' one certainly hopes.

But as a barrier to rude behaviour of other group co-workers?

Not necessarily.

Not sure extensive compiled-in perms checking would be more help than hindrance,
either (fresh scars from PostgreSQL biting me in the anatomy on that score not
24 hours ago).

Bill