[Fwd: [ mailman-Bugs-1188133 ] CGI group id not properly tested]

Hi Developers,
There is a rumor that mailman security check is not proper and recommending patch to void our security check. Can someone write a refutation to this article? (In a fluent English of course ;-)
-------- Original Message -------- Subject: [ mailman-Bugs-1188133 ] CGI group id not properly tested Date: Fri, 22 Apr 2005 07:58:37 -0700 From: SourceForge.net <noreply@sourceforge.net> Reply-To: mailman-developers@python.org To: noreply@sourceforge.net
Bugs item #1188133, was opened at 2005-04-22 15:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1188133&group_id=103
Category: Web/CGI Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Graham Klyne (grahamk) Assigned to: Nobody/Anonymous (nobody) Summary: CGI group id not properly tested
Initial Comment: [I tried to send this to mailman-developers, but my message was discarded]
I've just downloaded and installed the latest mailman 2.1.6rc1 and encountered a CGI permissions problem (running with Apache 2.0 on Scientific Linux 3.04), for which a patch is described in: http://minaret.biz/tips/mailman.html
(briefly, replace getgid with getegid in common.c)
Applying this patch resolves the problem I was experiencing.
Is there any reason this isn't applied in the mailman distribution?
#g
You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1188133&group_id=103
Mailman-coders mailing list Mailman-coders@python.org http://mail.python.org/mailman/listinfo/mailman-coders
-- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/

On Sat, 2005-04-23 at 06:53 +0900, Tokio Kikuchi wrote:
I believe Geoff Mottram may be confused with how mailman's security works.
Normally when a process is invoked it is run with the owner and group of the process that invoked it. It does not execute with the owner and group belonging to the executable (unless it is setuid or setgid respectively).
The mailman executable is setgid mailman. This means no matter who runs it, it will execute with its group set to mailman. Mailman's security is group based, anything mailman attempts to do will only succeed if the process attempting to perform the operation is a member of the mailman group. This is why the mailman "wrapper" is setgid mailman. No matter who invokes it, it runs as if it were a member of the mailman group (not the group of process that invoked it). Thus it has permission to perform mailman operations because it is executing as a member of the mailman group.
But wait! That means anybody can invoke the mailman wrapper program and perform mailman operations because the wrapper when it starts to execute will immediately assume the mailman group identity granting it full mailman permissions. Thus we need a way to say "only a select set of trusted processes can invoke me". In other words, if somebody askes me to run and do mailman operations, do I trust the entity that asked me to do this? The trust question is answered by identifying the group of the process that asked me to run, in short, "if you're not a member of a group I trust I refuse to perform mailman operations".
The group of the process that invoked mailman is the real group, this is the group that is being validated. If that validity check passes then all further operations occur under the effective group id of mailman, which is exactly what we want.
Thus Mr. Mottram has confused the role of the real and effective group id in the validation check because it is the real group id that identifies the process that invoked mailman, and it is this id that we need to validate is a trusted process. If the change he proposes were implemented, to test the effective id, then the trust question become "if I am me", which is trivally true because of the setgid property, then the validty check always succeeds no matter who invoked mailman and all security is defeated.
Note: I have only responded to this list, I have not updated the original bug posting.
-- John Dennis <jdennis@redhat.com>

Thank you John! I've updated the bug tracker. Mr. Mottram also changed his page after a little discussion with me.
John Dennis wrote:
(snip)
Note: I have only responded to this list, I have not updated the original bug posting.
-- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/

On Sat, 2005-04-23 at 19:58, Tokio Kikuchi wrote:
Thank you John! I've updated the bug tracker. Mr. Mottram also changed his page after a little discussion with me.
BTW, note that Postfix generally isn't susceptible to this misunderstanding because Postfix will run its mail programs using the user and group owner of the alias file the filter program is defined in. Because the typical Postfix+Mailman installation is using the /usr/local/mailman/data/aliases.db file that is group owned by mailman, --with-mail-gid=mailman /is/ the right value to use.
-Barry

On Sun, 2005-04-24 at 16:16 -0400, Barry Warsaw wrote:
Similar arrangements exist with exim. The normal policy with the exim/Mailman configuration is to set the invoking uid/gid for the mailman wrapper suit whatever mailman was built for. [This is particularly useful when you are using a packaged mailman, which was probably built by someone considering how things work for sendmail]
Nigel.
-- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ]

On Sat, 2005-04-23 at 06:53 +0900, Tokio Kikuchi wrote:
I believe Geoff Mottram may be confused with how mailman's security works.
Normally when a process is invoked it is run with the owner and group of the process that invoked it. It does not execute with the owner and group belonging to the executable (unless it is setuid or setgid respectively).
The mailman executable is setgid mailman. This means no matter who runs it, it will execute with its group set to mailman. Mailman's security is group based, anything mailman attempts to do will only succeed if the process attempting to perform the operation is a member of the mailman group. This is why the mailman "wrapper" is setgid mailman. No matter who invokes it, it runs as if it were a member of the mailman group (not the group of process that invoked it). Thus it has permission to perform mailman operations because it is executing as a member of the mailman group.
But wait! That means anybody can invoke the mailman wrapper program and perform mailman operations because the wrapper when it starts to execute will immediately assume the mailman group identity granting it full mailman permissions. Thus we need a way to say "only a select set of trusted processes can invoke me". In other words, if somebody askes me to run and do mailman operations, do I trust the entity that asked me to do this? The trust question is answered by identifying the group of the process that asked me to run, in short, "if you're not a member of a group I trust I refuse to perform mailman operations".
The group of the process that invoked mailman is the real group, this is the group that is being validated. If that validity check passes then all further operations occur under the effective group id of mailman, which is exactly what we want.
Thus Mr. Mottram has confused the role of the real and effective group id in the validation check because it is the real group id that identifies the process that invoked mailman, and it is this id that we need to validate is a trusted process. If the change he proposes were implemented, to test the effective id, then the trust question become "if I am me", which is trivally true because of the setgid property, then the validty check always succeeds no matter who invoked mailman and all security is defeated.
Note: I have only responded to this list, I have not updated the original bug posting.
-- John Dennis <jdennis@redhat.com>

Thank you John! I've updated the bug tracker. Mr. Mottram also changed his page after a little discussion with me.
John Dennis wrote:
(snip)
Note: I have only responded to this list, I have not updated the original bug posting.
-- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/

On Sat, 2005-04-23 at 19:58, Tokio Kikuchi wrote:
Thank you John! I've updated the bug tracker. Mr. Mottram also changed his page after a little discussion with me.
BTW, note that Postfix generally isn't susceptible to this misunderstanding because Postfix will run its mail programs using the user and group owner of the alias file the filter program is defined in. Because the typical Postfix+Mailman installation is using the /usr/local/mailman/data/aliases.db file that is group owned by mailman, --with-mail-gid=mailman /is/ the right value to use.
-Barry

On Sun, 2005-04-24 at 16:16 -0400, Barry Warsaw wrote:
Similar arrangements exist with exim. The normal policy with the exim/Mailman configuration is to set the invoking uid/gid for the mailman wrapper suit whatever mailman was built for. [This is particularly useful when you are using a packaged mailman, which was probably built by someone considering how things work for sendmail]
Nigel.
-- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ]
participants (4)
-
Barry Warsaw
-
John Dennis
-
Nigel Metheringham
-
Tokio Kikuchi