MESSAGE
| DATE | 2015-03-10 |
| FROM | Chris Knadle
|
| SUBJECT | Re: [NYLXS - HANGOUT] cable crimping
|
On 03/09/2015 05:05 AM, Rick Moen wrote:
>
> 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
If you look at the mailman_transport, that's a pipe transport.
In the mailman_router there's a lookup done on the local_part of the
email address for local_domains and passing the mail to Mailman via the
mailman_transport if there's a match. That's essentially duplicating
what /etc/aliases does, and still passes the mail via a pipe, but
running the command via MAILMAN_USER and MAILMAN_GROUP.
[...]
> 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.
This is the case by default, but not if you set the user and group in
the transport (such as they did in the Mailman example). Furthermore
if you look in section 29 concerning the pipe transport, there's an
allow_commands option to limit what commands a transport can call.
http://www.exim.org/exim-html-current/doc/html/spec_html/ch-the_pipe_transport.html
--------------------------------------------------------------------
allow_commands Use: pipe Type: string list†Default: unset
The string is expanded, and is then interpreted as a colon-separated
list of permitted commands. If restrict_to_path is not set, the only
commands permitted are those in the allow_commands list. They need not
be absolute paths; the path option is still used for relative paths. If
restrict_to_path is set with allow_commands, the command must either be
in the allow_commands list, or a name without any slashes that is found
on the path. In other words, if neither allow_commands nor
restrict_to_path is set, there is no restriction on the command, but
otherwise only commands that are permitted by one or the other are allowed.
--------------------------------------------------------------------
At least with Exim using a pipe via /etc/aliases doesn't /have/ to be
something terribly insecure. You do need to know what you're doing...
sure.
It looks like in one case I'm not actually using the command listed
in /etc/aliases and instead re-specifying the command in the transport,
but other cases where I am I'm using allow_commands to limit what can
be run (and specifying the current directory, user, group, etc).
But a piped command in /etc/aliases with no limiting on the command
or the user running it, etc -- yeah that I'd be concerned about.
-- Chris
--
Chris Knadle
Chris.Knadle-at-coredump.us
|
|
