Re: [Mailman-Users] Updated view on Sendmail integration

[Stephen J. Turnbull]

Dmitri Maziuk via Mailman-Users writes:
 > On Mon, 3 Dec 2018 10:30:53 -0500
 > Jim Ziobro  wrote:
 > ...
 > > 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.
 > 
 > So basically unix user/group access model is wrong because sendmail
 > is full of bugs?

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: turnb...@sk.tsukuba.ac.jp   University of Tsukuba
Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Updated view on Sendmail integration

[Dmitri Maziuk via Mailman-Users]

On Mon, 3 Dec 2018 10:30:53 -0500
Jim Ziobro  wrote:
...
> 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.

So basically unix user/group access model is wrong because sendmail is full of 
bugs?

-- 
Dmitri Maziuk 
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Updated view on Sendmail integration

[Mark Sapiro]

On 12/3/18 7:30 AM, Jim Ziobro wrote:
> 
> 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
> 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.


There's postfix_to_mailman.py. For our view of that, see
 and
.


> 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
> }


OK. What's the problem with this?


> 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:


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)



> 
> 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.


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
. We
are interested in help with Sendmail in this area.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

Re: [Mailman-Users] Cannot use mailman moderation over HTTPS, fix_url ineffective, mm_cfg.py does not apply

[Mark Sapiro]

On 12/4/18 4:35 AM, Nikolaos Andriopoulos wrote:
> 
> Things checked:
> - The web server configuration seems OK, and properly redirects to HTTPS.


Redirects of POST lose the POST data.


> - The current mm_cfg.py ( with comments omitted ) is the following:
> 
> from Defaults import *
> import pwd, grp
> 
> MAILMAN_UID = pwd.getpwnam('mailman')[2]
> MAILMAN_GID = grp.getgrnam('mailman')[2]
> 
> from socket import *
> try:
>   fqdn = getfqdn()
> except:
>   fqdn = 'mm_cfg_has_unknown_host_domains'
> 
> DEFAULT_URL_HOST   = fqdn
> DEFAULT_URL_PATTERN = 'http*s*://%s/mailman/'


This is correct, but the preceding stuff seems to be from some
downstream package which may explain why DEFAULT_URL_PATTERN is
apparently not effective.


> DEFAULT_EMAIL_HOST = fqdn
> 
> add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
> 
> - For old lists, using
> ./withlist -l -r fix_url mylistname -u lists.mydomain.com
>   does NOT change to form action to HTTPS, and new lists still have HTTP as
> an action.


which indicates that your mm_cfg.py setting for DEFAULT_URL_PATTERN is
not effective, possibly because the file you are editing is not the one
Mailman is using.


> I have copied over fix_url.py to fix_url2.py which hardcodes
>web_page_url =  'https://lists.mydomain.com/mailman/'
> 
> And apply it to all lists of each domain after creation to fix this, but it
> really seems that it should not be this way. Is there something I am
> missing as far as MailMan is concerned?


Mailman is spelled Mailman.

fix_url creates web_page_url from DEFAULT_URL_PATTERN. If the created
web_page_url is not https, either the mm_cfg it imports is not the one
you edited or the setting you edit is being overridden somehow.

There should be a Mailman/ directory containing Defaults.py, mm_cfg.py
and many other Mailman modules. Is this mm_cfg.py a file or a symlink?
If it is a file, is it the one you are editing? If it is a symlink, is
its target the file that you are editing.

Also, as far as new lists are concerned, you need to restart Mailman
after editing mm_cfg.py, but this shouldn't affect fix_url.

You could try running './withlist -i' and in the interactive session


>>> from Mailman import mm_cfg
>>> mm_cfg.DEFAULT_URL_PATTERN

This should print

'https://%s/mailman/'

If it doesn't, you need to figure out why it isn't importing from the
mm_cfg.py that you edited.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

[Mailman-Users] Cannot use mailman moderation over HTTPS, fix_url ineffective, mm_cfg.py does not apply

[Nikolaos Andriopoulos]

Hello,
I am responsible for a server with a number of lists on a server that has
Plesk installed (don't leave just yet!).

Mailman administrative interface loads over HTTPS, and every page in the
administration works as expected -- with the exception of message
moderation, which stubbornly keeps POSTing to plain HTTP.

Things checked:
- The web server configuration seems OK, and properly redirects to HTTPS.
- The current mm_cfg.py ( with comments omitted ) is the following:

from Defaults import *
import pwd, grp

MAILMAN_UID = pwd.getpwnam('mailman')[2]
MAILMAN_GID = grp.getgrnam('mailman')[2]

from socket import *
try:
  fqdn = getfqdn()
except:
  fqdn = 'mm_cfg_has_unknown_host_domains'

DEFAULT_URL_HOST   = fqdn
DEFAULT_URL_PATTERN = 'http*s*://%s/mailman/'
DEFAULT_EMAIL_HOST = fqdn

add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)

- For old lists, using
./withlist -l -r fix_url mylistname -u lists.mydomain.com
  does NOT change to form action to HTTPS, and new lists still have HTTP as
an action.

I have copied over fix_url.py to fix_url2.py which hardcodes
   web_page_url =  'https://lists.mydomain.com/mailman/'

And apply it to all lists of each domain after creation to fix this, but it
really seems that it should not be this way. Is there something I am
missing as far as MailMan is concerned?

Thank you in advance for your valuable assistance!
Nick.
--
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org

[Mailman-Users] Updated view on Sendmail integration

[Jim Ziobro]

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 
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(){
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(){ 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


--
Mailman-Users mailing list Mailman-Users@python