[Mailman-Developers] Q: Security checking in wrappers and config file

[Michael Tokarev]

Ok, thanks, Harald, for your interest.


Harald Meland wrote:
> 
> [Michael Tokarev]
> 
> > I looked to mailman wrappers code, and found that it performs some
> > strange to me fings.  First of all, it is seemed to be not good idea
> > to define uids/gids as numbers inside executable wrappers (for mail
> > and www).
> 
> These values are derived from whatever GIDs the configure script
> finds.  You can specify what group name to use with the
> "--with-mail-gid" and "--with-cgi-gid" configure options.

This is ok when you installed on the same system that the thing
was built on.  And moreother, that system shoud have that accounts
defined.  I, for example, prefer to build on one machine and install
on another -- I have inet-access server and build machine, the first
one lacks complier etc (compiler should not exists on router f.e.,
atleast for some strange security issues... :).  Another one cause
are the numerous distribution systems like rpm, deb etc that cames
in binary form, thus compiled on other system.  People still sometimes
prefer this.  And there is no guarantee, for example, so that rpm/deb
will install mailman's owner using the same uid/gid (f.e. if that ids
already used on target machine).  Also, if I reinstall (or have) another
mailer, I will need it's own tweaking or mailman's one (this is what
I have already -- postfix executes all programs defined in aliases files
owned by root as nobody; I tweaked postfix's config and added mailman's
aliases file that is owned by mail(!), as mailman expects to be called
with gid=mail).

Ok, it is not so important to make uid/gid configurable; but -- just why
to not add one extra call -- getXXXent -- to leave this in symbolic form?
This is trivial, no need to determine gid on compile time, and all incompats
with different uid/gid for the same name will go away.  Is it considered
security harmless?! -- this question I asked already.

> > I think that something caused the current approach when the code was
> > developed, but don't know what it was...
> >
> > Why not use the following schema:
> >
> > * made one config file in well-known place (e.g. /etc/mailman.conf)
> >   and require that it writable only by root (maybe)
> > * place all the info there (including mail gid, www gid,
> >   location of mailman "home" directory etc. (the last one
> >   will be PYTHON_PATH; also, it can be read using getpwnam)
> 
> Why?  What does this win us over the situation we have now?

There is paths.py file in each subdir.  Why just not to move it to /etc?

> The only "advantage" I can see is that you wouldn't have to recompile
> Mailman if some of the GIDs Mailman is invoked from change; editing
> the config file will suffice.  However, is that really a common enough
> occurence that we'd want to require a separate config file for it?

My suggestion (but that I not mention there) is to place all paths into
this file (e.g. logdir=xxx, listsdir=xxx etc).  uid/gid is not so useful
there as those things, but this will have small advantage (if I change
mailer etc).

> > * do not rely on setgid for mailman home, but instead use real
> >   setgid calls
> 
> Ummm, I don't think I understand what you mean...

Oh, I'm stupid... :)
I mean here:
mailman's _directories_ uses g+s mode.  So, all files created there will
have gid=mailman (e.g.) automatically.
This seemed to be just to easy installation.
All programs should be running with gid=mailman anyway -- why need g+s on dir!?

> > With current layout, it is not possible to split programs and data.
> 
> Not quite true; you can fake a split by substituting symlinks for the
> subdirs under $(prefix).

Yeah, it's true.  A bit ugly but true, and I already attempted to do
so.

> > I want to put all executables into, say, /usr/mailman, and all data
> > to /var/[spool/]mailman and /var/log/mailman (and mount /usr
> > read-only).  Having config file it is simple.
> >
> > Also, with current approach, many files will be owned by some
> > strange users when mailman operates.  For example, config.db file
> > owned by nobody (run from www) or whatether owner when run from MTA,
> > the same cab be with logs.  This is potentially unsecure, as, e.g.,
> > any other cgi script can read _and_ write this config file as a
> > result, not only mailman group.  Yes, rewriting is not very good
> > (not an atomic operation), but I prefer security here...
> 
> Ummm, I still don't follow you -- are you saying that we should use
> setuid instead of setgid stuff?

No.  I just suggest to have real file's owner (pre-created file,
not created anew).  If we have created all required files at install
time, we can preserve owners, but this requires owerriting them,
not creating+renaming.

> As for other cgi scripts being able to write lists' config.db files:
> Unless your web server user is a member of the mailman group,
> non-mailman-setgid cgi scripts may be stopped from accessing
> Mailman-internal data by
> 
>   chgrp mailman $(prefix)/lists
>   chmod o-rwx $(prefix)/lists
> 
> etc. (I think -- this is untested).

That is strange that this issue was not popped up before...
This is the first that I found strange (after numeric gids inside
wrappers) -- config is owned by nobody and by default accessable from
www.  And this is what I did right after -- chmod'ed o-wrx *, o+x cgi-bin etc.
Untested -- just strange that noone looked to this before.

> > And some more thoughts.
> > Many MTAs sets environment variables when delivering to programs.
> > For example, postfix sets LOGNAME to recipient name, DOMAIN to
> > part of recipient address after @, FROM to envelope address
> > and so on, and those variables are _safer_ to use (in case of
> > postfix) than information from mail contents (with both sides --
> > MTA can have more info available about real person who sends this
> > mail, based on, say, smtp AUTH commands, and, in case of postfix,
> > those values are already parsed by intelligent mechanism and with
> > all strange/funny/control characters removed).
> > Is it possible candidate to enhancement to include usage of those
> > variables?
> 
> Only if it would be a) safe and b) not too MTA-specific.  In the
> example you provide, I don't think those two criteria are satisfied --
> I'd either have to _explicitly_ tell Mailman that the MTA delivering
> to it is Postfix, or risk using heuristics to determine what MTA is
> doing the delivery.  I suppose heuristics might easily be fooled if I
> pass similar environment variables on to e.g. an Exim daemon.

This can be done using custom classes for different MTAs.  I don't know
how hard it is to implement.  You are definitely right here, too --
it is not a common scheme.  Some mailers are safe in that aspects.
I just curious a bit, and paranoid in security.  All from info
inside messages can be easily fooled as well, so, e.g., approve
can be fooled etc.  But if mta have, say, tls/sasl/etc extensions,
this can be used safely.  Not only based on env. vars, but on custom
headers added by that mta (say, X-SASL-User: xxx).

> > P.S. I'm new to this list... :)
> 
> Welcome!

Thanks. ;)

>           Hopefully me being rather sceptic to the changes you are
> proposing aren't ruining the first impression ;)

?? Sorry didn't understand you here... :)  Oh my bad English!..
Mailman seemed to me at least slightly different than many other software
that I seen before.  Some of it's principles, namely, numeric ids and
a mix of programs (read-only) and variable data, and also with some
file permissions.
Just wanted to see it good.  And maybe my own The Right Thing (tm) is
a bit different from yours ;)

> --
> Harald

Thanks.
Regards,
  Michael.