Updated view on Sendmail integration
I am still fairly new to Mailman but I have been a long time Sendmail user.I like to know how things work.Partly out of security paranoia and partly out of curiosity I started hacking around the MTA interface.
One of the things I now see is that Mailman depends on a group for access(vs. setuid).Sendmail does not like group accessible things files or directories based on a long history of security problems.Somewhere there has to be a bridge between the Mailman security model and Sendmail (or any other MTA).
Back in 2004 the approach was to create a shell scriptThat script would get executed as root.More on that later.
Another approach was mm-handler.Mm-handler handles the security bridge by calling back Mailman after it has switched to UID/GID: mailman/mailman.An elegant solution.The v3 version <http://sw.ziobro.info/mm-handler/>optionally allows mail not destined for a mailing list to be delivered locally.Thus mm-handler could be used to implement mailing lists in front of an existing mail domain.It looks like the mm-handler could be integrated into Postfix and probably other MTAs.I suspect passing all mail through mm-handler would be a performance drag for a busy mail system.It looks like leaving MTA set to ‘Manual’ is best but that generates a little irrelevant text.
If you want to mix Mailman mailing lists in with your regular mailboxes and aliases then the classic method of using the aliases file as generated by Mailman seems best.The 2004 instructions suggested using a shell script to copy the Mailman generated aliases file into /etc/mail/ configuration directory for Sendmail.See: https://mail.python.org/pipermail/mailman-users/2004-June/037518.html
Current distributions of Sendmail contain a file /etc/mail/make which is an appropriate place for such customization.The /etc/mail/make script gets executed every time Sendmail restarts.It is called once as “make aliases” and again as just “make” before Sendmail restarts.Instead of creating a shell script you could just edit the /etc/mail/make file so the makealiasesdb function reads:
makealiasesdb() { /usr/bin/cp /etc/mailman/aliases /etc/mail/mailman-aliases/usr/bin/newaliases > /dev/null }
I started wondering where the interface between Mailman and MTA should be defined.For example if I am using MTA=’Manual’ then I could setup my /etc/mail/make as:
makealiasesdb() {
/usr/lib/mailman/bin/genaliases > /etc/mail/mailman-aliases
/usr/bin/newaliases > /dev/null
}
But the ‘Manual’ mailer has no capability of signaling the MTA that the mailing lists have been updated.If I use MTA=’Postfix’ then genaliases has no output.Apparently the genaliases program is a function of the MTA setting.So I rolled my own aliases with a perl program:
#!/usr/bin/perl -w
# create the Mailman aliases file
open(A,"/usr/lib/mailman/bin/list_lists -b|") ||
exit(1); my @e= qw(admin bounces confirm join leave owner request subscribe unsubscribe);
while(<A>){ chop;
print "$_:\"|mailman post $_\"\n";
foreach my $x (@e){ print "$_-$x:\"|mailman $x $_\"\n"; }
print "owner-$_:$_-owner\n"; # Majordomo fans
}
The perl program can be stuffed into one line in the make shell script like this:
makealiasesdb() {
# genaliasesinto /etc/mail/mailman-aliases
/usr/bin/perl -e ' open(A,"/usr/lib/mailman/bin/list_lists -b|") || exit(1); my @e=qw(admin bounces confirm join leave owner request subscribe unsubscribe); while(<A>){ chop; print "$_:\"|mailman post $_\"\n"; foreach my $x (@e){ print "$_-$x:\"|mailman $x $_\"\n"; } print "owner-$_:$_-owner\n"; }' > /etc/mail/mailman-aliases
/usr/bin/newaliases > /dev/null }
Once the need for genaliases is gone I could simplify the MTA/Sendmail.py create function to:
def create(mlist, cgi=False, nolock=False, quiet=False):
# restart the mail program so new aliases are active
msg = 'command failed: %s (status: %s, %s)'
if not nolock:# NOT genaliases
acmd = mm_cfg.RESTART_MAILER_CMDstatus = (os.system(acmd) >> 8) & 0xffif status:errstr = os.strerror(status)syslog('error', msg, acmd, status, errstr)raise RuntimeError, msg % (acmd, status, errstr)
The RESTART_MAILER_CMD configuration will Default to: RESTART_MAILER_CMD = ‘sudo systemctl restart sendmail’
On older systems it might be: ‘sudo /etc/init.d/sendmail restart’
By moving the responsibility to create aliases out of Mailman the Mailman code base shrinks a lot.Smaller is better.It works for me.
Is the directory “/etc/mailman” group-writable only to support the creation of an aliases file?I would feel more confident if /etc/mailman was only writable by root.
This is where I am now.I cut and paste Python code but don’t necessarily understand it.If someone could give the Python code a look over then I’ll organize it a little better for a release.
This got a little long. Thanks for your attention!
Ciao,
//Z\\ Jim Ziobro
On 12/3/18 7:30 AM, Jim Ziobro wrote:
There's postfix_to_mailman.py. For our view of that, see <https://wiki.list.org/x/15564817> and <https://mail.python.org/pipermail/mailman-users/2012-September/074017.html>.
OK. What's the problem with this?
with MTA = 'Postfix' both genaliases and list creation/deletion update Mailman's data/aliases file and then run the command defined in POSTFIX_ALIAS_CMD. This is how aliases are automatically maintained with MTA = 'Postfix'.
If you want genaliases to write the aliases to stdout just set MTA = 'Manual' (the default)
<big snip>
At this point in the lifecycle of Mailman 2.1 I have no interest in implementing a 'Sendmail' MTA for Mailman. The method for adapting MTA = 'Postfix' for automatic alias maintenance with sendmail is documented and works.
Mailman3 does things differently. See <https://mailman.readthedocs.io/en/latest/src/mailman/docs/mta.html>. We are interested in help with Sendmail in this area.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Dmitri Maziuk via Mailman-Users writes:
Please, Dmitri. All large software applications are full of bugs (starting with the brain of Homo so-called Sapiens). It's only good sense to respect POMP[1].
That said, this *is* minimum privilege. Mailman should *not* run as root. Sendmail should only be accessing /etc/mailman via a link to a specific file, and Mailman needs to be able to write that. QED. Even if you use a Postfix-like multiple executable model with a dedicated suid root binary to write Mailman's alias file, Mailman still specifies the content. (Yes, you could fiddle the system such that genaliases only overwrites an existing file, but that is fragile at best, and still give Mailman's user limited access to /etc/mailman.)
So Dmitri does have a point. If you don't trust Mailman or your webserver (the two applications that should be running with Mailman group privileges), you're screwed anyway. I don't see why it matters whether the evil thing is in /etc/mailman (which only Mailman should be generically accessing: other applications should only rarely even read specific files there, such as an alias include file), or squirreled away elsewhere in Mailman-owned trees or those of the webserver. Saying a webserver that produces dynamic content and even reconfigures other applications should live entirely in read-only storage is a paradox.
Steve
Footnotes: [1] The Principle of Minimum Privilege.
-- Associate Professor Division of Policy and Planning Science http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnbull@sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN
On Wed, 5 Dec 2018 10:28:53 +0900 "Stephen J. Turnbull" <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Dmitri Maziuk via Mailman-Users writes:
Yes, and then there's sendmail ;)
I find that often, if you have a clear and concise problem statement, the solution will point to itself. Case in point: a) don't use unix, b) don't use sendmail, c) invest in SElinux labels.
-- Dmitri Maziuk <dmaziuk@bmrb.wisc.edu>
On 12/3/18 7:30 AM, Jim Ziobro wrote:
There's postfix_to_mailman.py. For our view of that, see <https://wiki.list.org/x/15564817> and <https://mail.python.org/pipermail/mailman-users/2012-September/074017.html>.
OK. What's the problem with this?
with MTA = 'Postfix' both genaliases and list creation/deletion update Mailman's data/aliases file and then run the command defined in POSTFIX_ALIAS_CMD. This is how aliases are automatically maintained with MTA = 'Postfix'.
If you want genaliases to write the aliases to stdout just set MTA = 'Manual' (the default)
<big snip>
At this point in the lifecycle of Mailman 2.1 I have no interest in implementing a 'Sendmail' MTA for Mailman. The method for adapting MTA = 'Postfix' for automatic alias maintenance with sendmail is documented and works.
Mailman3 does things differently. See <https://mailman.readthedocs.io/en/latest/src/mailman/docs/mta.html>. We are interested in help with Sendmail in this area.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Dmitri Maziuk via Mailman-Users writes:
Please, Dmitri. All large software applications are full of bugs (starting with the brain of Homo so-called Sapiens). It's only good sense to respect POMP[1].
That said, this *is* minimum privilege. Mailman should *not* run as root. Sendmail should only be accessing /etc/mailman via a link to a specific file, and Mailman needs to be able to write that. QED. Even if you use a Postfix-like multiple executable model with a dedicated suid root binary to write Mailman's alias file, Mailman still specifies the content. (Yes, you could fiddle the system such that genaliases only overwrites an existing file, but that is fragile at best, and still give Mailman's user limited access to /etc/mailman.)
So Dmitri does have a point. If you don't trust Mailman or your webserver (the two applications that should be running with Mailman group privileges), you're screwed anyway. I don't see why it matters whether the evil thing is in /etc/mailman (which only Mailman should be generically accessing: other applications should only rarely even read specific files there, such as an alias include file), or squirreled away elsewhere in Mailman-owned trees or those of the webserver. Saying a webserver that produces dynamic content and even reconfigures other applications should live entirely in read-only storage is a paradox.
Steve
Footnotes: [1] The Principle of Minimum Privilege.
-- Associate Professor Division of Policy and Planning Science http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnbull@sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN
On Wed, 5 Dec 2018 10:28:53 +0900 "Stephen J. Turnbull" <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Dmitri Maziuk via Mailman-Users writes:
Yes, and then there's sendmail ;)
I find that often, if you have a clear and concise problem statement, the solution will point to itself. Case in point: a) don't use unix, b) don't use sendmail, c) invest in SElinux labels.
-- Dmitri Maziuk <dmaziuk@bmrb.wisc.edu>
participants (4)
-
Dmitri Maziuk -
Jim Ziobro -
Mark Sapiro -
Stephen J. Turnbull