MESSAGE
| DATE | 2015-03-09 |
| FROM | Rick Moen
|
| SUBJECT | Re: [NYLXS - HANGOUT] cable crimping
|
Quoting Chris Knadle (Chris.Knadle-at-coredump.us):
>
> On 03/08/2015 01:45 PM, Rick Moen wrote:
> >
> > Quoting Ruben Safir (mrbrklyn-at-panix.com):
> >
> >> Robert, do you have the artcile for me, PLEASE
> >
> > I hope he does _not_ have the 'cheap $5 crimper' for you. Life is too
> > short to spend it using crummy tools, like poorly made crimpers (and
> > proprietary mailing list managers with designed-in security holes that
> > have been unmaintained for a decade and a half).
>
> If you've managed to set up Mailman such that you're not passing it
> the mail via a pipe in /etc/aliases, then from what I'm hearing
> you're probably the only one that's gotten that to work.
Here's the way to make the Exim4 MTA directly read GNU Mailman
conffiles, rather than needing special entries with pipes in
/etc/aliases:
http://anonscm.debian.org/viewvc/pkg-mailman/trunk/debian/README.Exim4.Debian?view=markup
Notice that Exim4 actually uses Mailman's Postfix interface hooks needed
to provide the router and transport needed, so I imagine it's less
complicated with Postfix (Which I don't run here).
I _think_ this doc describes how to do the same sort of thing with
Postfix talking directly to the Sympa MLM (but I don't know Sympa very
well):
http://www.sympa.org/faq/postfix#managing_aliases_directly_in_the_postfix_transport_table
(If that's not the doc required, ask the sysadmin team at Linux Users of
Victoria. They run Sympa, and I remember them saying they didn't need
/etc/aliases entries.)
> As I've set up two MLMs in the past year and they both use a pipe in
> /etc/aliases, it would be nice to know what security issues you think
> this has.
You need to be completely sure that whatever's on the right hand side of
the pipe can handle any arbitrary public data passed through to it by
the MTA, i.e., that it has excellent input validation.
There's been such a _very_ bad history of that generally (easist
examples for me to recall have involved the old uudecode and decode
entries that used to be standard in /etc/aliases) that many modern MTAs
disable _all_ processing of /etc/aliases pipes by default.
Here's what /usr/share/doc/exim4/README.Debian.html has to say about
that, FWIW:
2.9. Using more complex deliveries from alias files
Delivery to arbitrary files, directory or to pipes in the
/etc/aliases file is disabled by default in the Debian Exim 4
packages. The delivery process including the program being piped to
would run as the exim admin-user Debian-exim, which might
open up security holes.
Invoking pipes from /etc/aliases file is widely considered obsolete
and deprecated. The Debian Exim package maintainers would
like to suggest using a dedicated router/transport pair to invoke
local processes for mail processing. For example, the Debian
mailman package contains a /usr/share/doc/mailman/README.Exim4.Debian
file that gives a good example how to implement this.
Using a dedicated router/transport pair have the following
advantages:
* The router/transport pair can be put in place by another package,
giving a well-defined transaction point between Exim 4
and $PACKAGE.
* Not allowing pipe deliveries from alias files makes it harder to
accidentally run programs with wrong privileges.
* It is possible to run different pipe processes under different
accounts.
* Even if only invoking a single local program, it is easier to do
with your dedicated router/transport since you won't need
to change this file, making automatic updates of this file
possible for future versions of the Exim 4 packages. If you do
local changes here, dpkg conffile handling will bother you on
future updates.
If you insist on using /etc/aliases in the traditional way, you will
need to activate the respective functions by setting the
transport options on the system_aliases router appropriately. Macros
are defined to make this easier. See
/etc/exim4/conf.d/router/400_exim4-config_system_aliases for
information about which macros are available. You might find the
address_file, address_pipe and/or address_directory transports that
are used for the userforward router helpful in writing your
own transports for use in the system_aliases router.
If any of your aliases expand to pipes or files or directories you
should set up a user and a group for these deliveries to run
under. You can do this by setting the "user" and - if necessary - a
"group" option and adding a "group" option if necessary.
Alternatively, you can specify "user" and/or "group" on the
transports that are used.
|
|
