Red Hat Bugzilla – Bug 125397
have more files owned by root
Last modified: 2007-11-30 17:10:44 EST
Description of problem:
Directories which do not have to be changed by mailman should
be owned by root:root to more security.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
I'm happy to change it, but I'm not sure I fully understand the issue
and would like to before modifying the package.
Here is the snippet from the Makefile:
# Modes for directories and executables created by the install
# process. Default to group-writable directories but
# user-only-writable for executables.
All files and directories in mailman are owned by root in the group
"mailman" and the only member of the mailman group is the "system
user" mailman which has no login. The directores are sgid. Scripts are
only allowed to run if they are a member of the mailman group.
Therefore only root and a member of the mailman group can write into
these directories. Where is the security hole that is being fixed by
changing the directory mode?
However please note we patch the allowed groups, which is documented
at the top of the patch and copied here for your review.
Mailman security is in part enforced by requiring it execute
SGID. When the mail process or the web server attempts to execute a
mailman script a C program is invoked to verify the group
permission. Mailman as it is shipped only allows one group to be
specified at build time. For users who build and install on their own
machine this is not a limitation. However, when making a binary
package to be installed on an arbitrary machine it is hard to predict
the correct group to use for that installation. Therefore this patch
allows us to specify at build time a list of groups that will be
iterated over, if the mailman process is executing as any of one of
the group in the set of groups then the permission check passes. Since
the groups we build with are limited to a small number of safe groups
this does not lower the security much while at the same time provides
a much more friendly way to package a binary installation that will
run in a wider range of installations.
From the spec file:
# Now, the groups your mail spoolers run as. Sendmail uses 'mail'(12)
# and postfix used to use 'nobody', but now uses 'postfix'
%define mailgroup "mail postfix mailman nobody"
By opening up the set of groups we allow an MTA to run mailman scripts
as we weaken some of the security, but given we don't control how our
customers chose and configure their MTA's this is almost a necessity.
This is the one area I'm aware of where we have some security exposure
and perhaps this needs to be tighted up.
Perhaps you could comment on the directory permissions vulnerability a
bit more and if we need to tighten up the group access of MTA's?
BTW, forgot to add that the only reason I'm asking about the
motivation instead of "just doing it" is mailman comes with a script
to validate the permissions and ownership of all its files and
directories and these are documented in various places so there is a
certain expectation in the user community as to what they are. So
before we introduce a Red Hat only deviation I want to make sure we
can justify the divergance. There has already been some complaints
about Red Hat changing things.
Motivation from my side was that the mailman scripts could have a bit
better security if only root can actually change them.
If this breaks other mailman scripts or the layout of the current
directory trees make this tricky, you might want to close this item.
Keeping to upstream is also a plus.
Can we should either move this bug upstream along with the rationale and close
this one. Having this here infinitely doesnt seem like a good idea
All the python code, the command line utilities, and the scripts executed by the
MTA and the web browser are owned by root. There are in the group mailman, which
they must because of the design of mailman security. Plus Mailman is fully
integrated with our SELinux security policy at this point providing extra
strength security. I'm closing this as not-a-bug. I don't see an issue here, or
at least not an issue which is not fundamentally present in the upstream