Re: Patch to run as "nullmail"

On 5/31/05, Dan Stromberg <[email protected]> wrote:
> On Tue, 2005-05-31 at 12:35 -0600, Charles Cazabon wrote:
> > Dan Stromberg <[email protected]> wrote:
> > > > > Are there any problems with this configuration?
> > > >
> > > > Running as that user is fine, but it shouldn't require the addition=
 of any
> > > > code to nullmailer.  This can be done in the shellscript that runs
> > > > nullmailer using any tool you like -- the djb-esque approach is
> > > > `setuidgid` or similar.
> > >
> > > Call me strange, but I believe that although this functionality isn't=
 needed
> > > by advanced users, it would likely be a big benefit to users who don'=
t
> > > realize they should be decreasing privilege as an extra step.
> >
> > Doesn't it seem silly/strange to add extra application-specific code (w=
hich
> > then needs to be documented, maintained, tested, and debugged) to add z=
ero
> > extra functionality?
> >
> > Adding extra code also increases the chance of a security problem, so i=
t's
> > counter-productive.

I would agree somewhat, but wouldn't running nullmailer as a
privileged user be an even bigger security risk?

The code to change privileges IS IN the djb-esque tools, which wraps
nullmailer-send. So how does that not add a "security problem" to the
overall effect? Code is code, wrapper or not. I don't think adding a
couple of lines directly to the app to change privilges adds much of a
security risk. Besides, the code to accomplish this uses proven code
that has been in existance since the AT&T UNIX days; probably not much
of a vulnerability.

The OpenBSD guys like to modify default network daemons to run as
unprivilged users right out of the box, without user intervention.
(ex: BIND named runs as named). I think this is smart and proactive
security.

As far as extra documentation is concerned, I think things would be
much more straightforward. You wouldn't have to document how to run
unprivilged via a monitoring service, you just run it. Besides, the
documention and the install script anticipate nullmailer-send to be
run as the user "nullmail", so why not let it run as nullmail out of
the box?

I made this patch to my nullmailer code so I could easily create a
package and install it on all of my servers with ease. I don't want to
run Daemon Tools on my servers. To me, that's just one more
application I need to maintain.

Anyway, I'm just making a suggestion. Thanks for the feedback.

Regards,
Clint