Re: Import of DragonFly Mail Agent

On Mon, Feb 24, 2014 at 07:01:54PM +0400, Slawa Olhovchenkov wrote:
> On Mon, Feb 24, 2014 at 03:30:14PM +0100, Baptiste Daroussin wrote:

> > On Mon, Feb 24, 2014 at 06:17:37PM +0400, Slawa Olhovchenkov wrote:
> > > On Sun, Feb 23, 2014 at 10:11:56PM +0100, Baptiste Daroussin wrote:

> > > > As some of you may have noticed, I have imorted a couple of days
> > > > ago dma (DragonFly Mail Agent) in base. I have been asked to
> > > > explain my motivation so here they are.

> > > What's about suid, security separations & etc?

> > What do you mean? dma is changing user as soon as possible, dma will
> > be capsicumized, what else do you want as informations?

> sendmail (in the past) have same behaviour (run as root and chage
> user).
> This is some security risk.
> For many  scenario change user is not simple (for example -- send file
> from local user A to local user B, file with permsion 0400).
> sendmail will be forced to change behaviour -- mailnull suid program
> for place mail into queue and root daemon for deliver to user.
> This is more complex.
> Can be dma avoid this way?

I'm a bit disappointed that dma uses setuid/setgid binaries, although it
is not a regression because sendmail also uses this Unix misfeature.

To avoid the large attack surface of set*id binaries (the untrusted user
can set many process parameters, pass strange file descriptors, send
signals, etc), I think it is better to implement trusted submission
differently. A privileged daemon (not necessarily running as root) can
listen on a Unix domain socket and use getpeereid(3) to verify the
credentials of the client.

Note that the largest gain with set*id binaries is obtained when the
last set*id binary is removed; we are pretty far from that.

-- 
Jilles Tjoelker