security/courier-authlib and courier user

[Yarema]

--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.

    --with-mailuser=userid, --with-mailgroup=groupid

   "userid" is a reserved system username, "groupid" is a reserved system
   groupname. These two options should be used before installing Courier for
   the first time. These options are not required before installing
   Courier-IMAP or SqWebMail.

   These options specify the user/group that will own the configuration
   files, and the socket that authentication daemon process listens on. This
   is a key part of Courier's security model.

   These options should not be necessary if upgrading from an earlier 
version
   of Courier and/or this authentication library. The default userid and
   groupid are computed as follows:

     * If an earlier version of the Courier authentication library is 
already
       installed in the same directory, the userid and the groupid is the
       same as the earlier version, otherwise:
     * If an earlier version of the Courier package is installed (only the
       Courier package, the Courier-IMAP and SqWebMail packages do not carry
       this information), the userid and the groupid is the same as the ones
       used to configure Courier, otherwise:
     * The userid is the first userid from the following list which exists 
in
       the system: courier, daemon, adm, bin, root; and the groupid is the
       first groupid from the following list which exists in the system:
       courier, daemon, adm, sys, root.

   When installing Courier authentication library for the first time, it is
   highly recommended to create a "courier" userid and groupid, so that
   specifying these options will not be necessary.

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.

I considered this when I first presented Oliver with the courier-authlib 
patches including UID/GID "courier".  My thinking at the time was that it 
might be even better if we actually had another sandbox UID/GID like 
"authlib" for instance.  The only thing that breaks is courier MTA's 
webadmin CGI.  What it gains us is more finegrained privilege separation 
where courier MTA would run as user "courier" and courier-authlib would run 
as user "authlib" and the two would not be able to corrupt each other in 
case of a vulnerability in either one of them.  As for the other courier 
packages like SqWebMail and courier-imap -- they don't need courier-authlib 
to run as user "courier" per se, but running courier-authlib under a 
UID/GID not used by anything else does benefit security regardless if that 
UID is "courier" or "authlib" or "sasl" or "auth" or whatever else.  I was 
actually thinking that it wouldn't be such a bad idea if we had a UID/GID 
such as "sasl" or "auth" which could be shared by a number of packages 
which functionally do similar things like cyrus-sasl and courier-authlib. 
If cyrus-sasl ran under user "sasl" so could courier-authlib. Look at how 
user "www" is used.  Apache uses it and so can any of the other http 
servers.  So why not have an "auth" UID reserved for packages like 
cyrus-sasl and courier-authlib?

So to sum up a) running courier-authlib under a UID not used by anything 
else is a Good Thing for security. b) Having that UID be "courier" makes it 
play nice with courier MTA's webadmin and kills two birds with one stone in 
having only one UID to manage for both packages.  c) Having the courier MTA 
package maintain user "courier" and having courier-authlib use a different 
UID is an option which would break webadmin but gain even more finegrained 
privilege separation.  d) Have courier-authlib run as "root" is a Bad Thing 
from a security viewpoint.

Them are my thoughts on this..
-- 
Yarema
http://yds.CoolRat.org