security/courier-authlib and courier user

[Jose M Rodriguez]

El Domingo, 24 de Julio de 2005 20:43, Yarema escribió:
> --On Sunday, July 24, 2005 16:44:14 +0200 Jose M Rodriguez
>
> <josemi at freebsd.jazztel.es> wrote:
> > El Domingo, 24 de Julio de 2005 15:29, Oliver Lehmann escribió:
> >> Jose M Rodriguez wrote:
> >> > Hi,
> >> >
> >> > After using courier-authlib with maildrop (from sendmail) and
> >> > courier-imap, I can't see any reason to have a courier user.
> >> >
> >> > This seems more a need of the courier mailer, and maybe of the
> >> > tarball build/install system (I doubt).
> >> >
> >> > So, I'm thinking about the convenience of don't do any courier
> >> > user work and do a rcNg for the courier mailer that fire-up all
> >> > the components (and not use courier-authlib rcNG for courier
> >> > mailer). I think the courier user only matters to the courier
> >> > mailer.
> >>
> >> "For the Courier mail server, /var/run/courier/authdaemon should
> >> be owned by the userid that Courier is installed under, and it
> >> must be readable and writable by the Courier user and group (but
> >> no world permissions)."
> >>
> >> How can I do this if I don't create the courier user with
> >> courier-authlib?
> >
> > First, this needs test, but I think that the real problem is
> > using /usr/local/etc/rc.d/courier-authdaemond.sh with courier
> > mailer.
> >
> > I think courier mailer users must maintain
> > courier_authdaemond_enable to NO and embed
> > /usr/local/etc/rc.d/courier-authdaemond.sh functonality in its own
> > rc script.
> >
> > This have more sense with the closed concept of the courier mailer.
> >
> > Also thinking in support ${courier_authdaemond_user:=root}
> > in /usr/local/etc/rc.d/courier-authdaemond.sh
> >
> > --
> >   josemi
>
> First let me quote the relevent portion of
> http://www.Courier-MTA.org/authlib/INSTALL.html then I'll add my
> thoughts on this.
> <snip/>
> In the all inclusive courier MTA having the courier-authlib config
> files owned by UID/GID "courier" allows the webadmin CGI to be used
> to administer all things courier including courier-authlib.  But more
> importantly having user "courier" improves security  by sandboxing
> the daemons into running under a UID/GID not used by anything else. 
> Yes, according to the docs above we could use user "daemon" or any
> number of other pre-existing UIDs. But that goes against the thinking
> of current security practice that having daemons with any security
> implications run under a sandbox UID/GID is a Good Thing.  I mean,
> the OpenBSD folks go to great lengths to include privilege separation
> into everything they run just in case there might be a vulnerability
> which could wreak havoc if the daemon was running with root
> privileges.  Also look at how the functionally closest package to
> courier-authlib does things: cyrus-sasl installs and uses UID/GID
> cyrus. And again the main reason is sandboxing or privilege
> separation if you will.

config (${PREFIX}/etc) owned by courier seems a good point to maintain 
things as used now.

--
  josemi