Re: Import of DragonFly Mail Agent

On Mon, Feb 24, 2014 at 11:50:10PM +0100, Jilles Tjoelker wrote:
> 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.
> 
As long as $anyone locally can send emails, what is the point of checking
getpeereid(3)?

regards,
Bapt