--On April 20, 2007 7:54:45 PM -0500 Jeffrey Goldberg
<[EMAIL PROTECTED]> wrote:
I think I'm beginning to understand where that "nobody" comes from and
why you are right about that.
Here is an excerpt from the postfix aliases(5)
In the absence of a user context, the local(8) daemon uses the
owner
rights of the :include: file or alias database. When those files
are
owned by the superuser, delivery is made with the rights specified
with
the default_privs configuration parameter.
I had been looking at the first half of that (which I was already aware
of). So I thought that if the wrapper were compiled to only run as
"nobody" than the relevant alias files had to be owned by "nobody". I
wasn't, until looking this up, aware of what happens when the aliases
file is owned by root.
In the postfix out of ports on FreeBSD, default_privs is set to "nobody".
So the first fix (modifying the owner of data/aliases{,.db}) is the
right way to go, but instead of making those files owned by "nobody"
(which does seem dangerous because than anything running as "nobody"
could change those file) they should be owned by root with mailman as
the group and permissions like 664.
Nobody is an unprivileged user.
grep nobody /etc/passwd
nobody:*:65534:65534:Unprivileged user:/nonexistent:/usr/sbin/nologin
So, using that account would *increase*, not decrease, security.
However....
Let me just test that now... Yes. Mail delivery seems to work with
[EMAIL PROTECTED] /usr/local/mailman/data]$ ls -la .
total 78
drwxrwsr-x 2 root mailman 1024 Apr 19 16:03 .
drwxrwsr-x 20 mailman mailman 512 Mar 30 13:57 ..
-rw-r----- 1 root mailman 41 Sep 11 2006 adm.pw
-rw-rw---- 1 root mailman 3523 Mar 31 16:10 aliases
-rw-rw-r-- 1 root mailman 16384 Mar 31 16:10 aliases.db
-rw-rw-r-- 1 root mailman 12288 Sep 13 2006 aliases.db.rpmsave
-rw-r----- 1 root mailman 41 Sep 11 2006 creator.pw
-rw-r--r-- 1 root mailman 10 Mar 30 13:57 last_mailman_version
-rw-rw---- 1 root mailman 4 Apr 17 14:34 master-qrunner.pid
-rw-r--r-- 1 root mailman 14114 Mar 30 13:57 sitelist.cfg
-rw-rw---- 1 root mailman 3334 Mar 31 16:10 virtual-mailman
-rw-rw-r-- 1 root mailman 16384 Mar 31 16:10 virtual-mailman.db
I haven't yet tested list creation, but the permissions look fine to me.
All of the relevant files (as well as the data directory itself) are
writable by members of the mailman group.
But I think I now see the problem
$ ../bin/check_perms
/usr/local/mailman/data/aliases.db owned by root (must be owned by
mailman
/usr/local/mailman/data/virtual-mailman.db owned by root (must be owned
by mailman
Problems found: 2
Re-run as mailman (or root) with -f flag to fix
Somehow check_perms doesn't seem to know how postfix does things. If I
were to actually run
check_perms -f
it would break to ownership of the aliases file so that we would have
the mismatch between what the uid postfix gives the the wrapper
("mailman") and what the wrapper demands ("nobody").
Nope. I've been running mailman for years now, and it works perfectly
fine. The owner of the data directory is mailman, and the group is
mailman.
ls -lsa /usr/local/mailman/data/
total 132
2 drwxrwsr-x 2 mailman mailman 512 Apr 7 19:47 .
2 drwxrwsr-x 20 mailman mailman 512 Nov 28 17:48 ..
48 -rw-r--r-- 1 mailman mailman 65536 Sep 6 2005 .db
2 -rw-r----- 1 mailman mailman 41 Sep 6 2005 adm.pw
6 -rw-r--r-- 1 root mailman 4383 Oct 14 2005 aliases
4 -rw-r----- 1 mailman mailman 3984 Sep 8 2005 aliases.bak
48 -rw-r----- 1 mailman mailman 49152 May 5 2006 aliases.db
0 -rw-rw-rw- 1 mailman mailman 0 Sep 9 2005
bounce-events-00446.pck
0 -rw-rw-rw- 1 mailman mailman 0 Sep 9 2005
bounce-events-00449.pck
0 -rw-rw-rw- 1 mailman mailman 0 Sep 9 2005
bounce-events-00467.pck
0 -rw-rw-rw- 1 mailman mailman 0 Jan 27 2006
bounce-events-00567.pck
0 -rw-rw-rw- 1 mailman mailman 0 Oct 13 2005
bounce-events-38840.pck
2 -rw-r----- 1 mailman mailman 41 Sep 6 2005 creator.pw
2 -rw-r--r-- 1 root mailman 10 Nov 28 17:48 last_mailman_version
2 -rw-rw---- 1 mailman mailman 4 Apr 1 08:31 master-qrunner.pid
14 -rw-r--r-- 1 root mailman 14114 Nov 28 17:48 sitelist.cfg
It is the *group* that matters to postfix, *not* the owner. Per the
pkg-message file:
Mailman has been installed, but requires further configuration before use!
You will have to configure both your MTA (mail server) and web server to
integrate with Mailman. If the port's documentation has been installed,
extensive post-installation instructions may be found in:
%%DOCSDIR%%/FreeBSD-post-install-notes
Note (1): If you use an alternate (non-Sendmail) MTA, you MUST be sure
that the correct value of MAIL_GID was used when this port or package
was built. Performing a "make options" in the Mailman port directory
will list required values for various mail servers.
Note that MAIL_GID is what matters. That is the *group* not the owner of
the files. Note also that the group only has read writes to the aliases
file, although it does have read/write access to the bounce-events files.
So maybe the problem is with check_perms and not with the port at all
(well the port would still need to get the aliases files owned by root).
There's nothing at all wrong with the check_perms script.
While setting the aliases files to be owned by "nobody" or by making the
wrapper want "mailman" instead of "nobody" would be work-arounds, both
of those lose out on the security achieved by having the aliases files
owned by root.
There's no increased benefit of having root own the aliases file. In
fact, while root owns the aliases db for postfix:
ls -lsa /usr/local/etc/postfix/aliases*
4 -rw-r--r-- 1 root wheel 2923 Feb 11 22:11
/usr/local/etc/postfix/aliases
48 -rw-r--r-- 1 root wheel 49152 Feb 11 22:11
/usr/local/etc/postfix/aliases.db
mailman owns the aliases db for mailman:
ls -lsa /usr/local/mailman/data/aliases*
6 -rw-r--r-- 1 root mailman 4383 Oct 14 2005
/usr/local/mailman/data/aliases
4 -rw-r----- 1 mailman mailman 3984 Sep 8 2005
/usr/local/mailman/data/aliases.bak
48 -rw-r----- 1 mailman mailman 49152 May 5 2006
/usr/local/mailman/data/aliases.db
And this is a working setup of mailman and postfix that's been running for
years.
Of course my two previous "understandings" of how things were supposed
to work were wrong. So please take my current analysis with a large
grain of salt.
Done.
Paul Schmehl ([EMAIL PROTECTED])
Senior Information Security Analyst
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/
