Date: Sun, 24 Jul 2005 14:43:27 -0400 From: Yarema <yds@CoolRat.org> To: Jose M Rodriguez <josemi@freebsd.jazztel.es>, Oliver Lehmann <oliver@freebsd.org> Cc: ports@freebsd.org Subject: Re: security/courier-authlib and courier user Message-ID: <D8FEAD2A55A14B6EC96CC90C@tuber.coolrat.org> In-Reply-To: <200507241644.15692.josemi@redesjm.local> References: <200507241509.44752.josemi@redesjm.local> <20050724152908.542dc3e8.oliver@FreeBSD.org> <200507241644.15692.josemi@redesjm.local>
next in thread | previous in thread | raw e-mail | index | archive | help
--On Sunday, July 24, 2005 16:44:14 +0200 Jose M Rodriguez=20
<josemi@freebsd.jazztel.es> wrote:
> El Domingo, 24 de Julio de 2005 15:29, Oliver Lehmann escribi=F3:
>> 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:=3Droot}
> in /usr/local/etc/rc.d/courier-authdaemond.sh
>
> --
> josemi
First let me quote the relevent portion of=20
http://www.Courier-MTA.org/authlib/INSTALL.html then I'll add my thoughts=20
on this.
--with-mailuser=3Duserid, --with-mailgroup=3Dgroupid
"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=20
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=20
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=20
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=20
owned by UID/GID "courier" allows the webadmin CGI to be used to administer =
all things courier including courier-authlib. But more importantly having=20
user "courier" improves security by sandboxing the daemons into running=20
under a UID/GID not used by anything else. Yes, according to the docs=20
above we could use user "daemon" or any number of other pre-existing UIDs.=20
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=20
Good Thing. I mean, the OpenBSD folks go to great lengths to include=20
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=20
privileges. Also look at how the functionally closest package to=20
courier-authlib does things: cyrus-sasl installs and uses UID/GID cyrus.=20
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=20
patches including UID/GID "courier". My thinking at the time was that it=20
might be even better if we actually had another sandbox UID/GID like=20
"authlib" for instance. The only thing that breaks is courier MTA's=20
webadmin CGI. What it gains us is more finegrained privilege separation=20
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=20
case of a vulnerability in either one of them. As for the other courier=20
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=20
UID/GID not used by anything else does benefit security regardless if that=20
UID is "courier" or "authlib" or "sasl" or "auth" or whatever else. I was=20
actually thinking that it wouldn't be such a bad idea if we had a UID/GID=20
such as "sasl" or "auth" which could be shared by a number of packages=20
which functionally do similar things like cyrus-sasl and courier-authlib.=20
If cyrus-sasl ran under user "sasl" so could courier-authlib. Look at how=20
user "www" is used. Apache uses it and so can any of the other http=20
servers. So why not have an "auth" UID reserved for packages like=20
cyrus-sasl and courier-authlib?
So to sum up a) running courier-authlib under a UID not used by anything=20
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=20
UID is an option which would break webadmin but gain even more finegrained=20
privilege separation. d) Have courier-authlib run as "root" is a Bad Thing =
from a security viewpoint.
Them are my thoughts on this..
--=20
Yarema
http://yds.CoolRat.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D8FEAD2A55A14B6EC96CC90C>