On 4 Sep 2000 [EMAIL PROTECTED] wrote:
I see... well, maybe we can take a look at it. In the meantime, if you
figure out a patch that doesn't rely on an external program, let me
> Chris McDonough <[EMAIL PROTECTED]> wrote:
> >Aplogies for the ignorance, but can you maybe explain the concept
> >of supplemental group ids and give an example of how the current unpatched
> >behavior could be subverted?
> I can try...
> Supplemental gids are useful for allowing a user to belong to more
> than one group, or maybe to more than one project in normal parlance.
> This is normally effected by listing the uid opposite more than one
> group in /etc/group. The login process issues the initgroups(3) call
> to install these supplemental groups, which are inherited by all
> processes forked from the login shell.
> The problem is comes when you change user ids; for example what I
> saw with Zope (start -u nobody) was:
> before change after change
> ============= ============
> user id root nobody
> group id root nobody
> sup id(s) root root
> Thus the process has group access privilages for nobody (correct) and
> root (bad) in unpatched Zope.
> I cannot give you an exploit based on this -- my knowledge of Zope
> is not deep enough -- and in a bug free world there probably would
> be no exploit. But the reason for running as nobody, I think, is
> to contain damage should an exploit be found. For that reason, it
> would seem reasonable to change the supplemental gids too.
> I saw this on Linux; supplemental groups come from the BSD tradition,
> so you likely will find the same situation on *BSD, Solaris, etc.
> Zope maillist - [EMAIL PROTECTED]
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://lists.zope.org/mailman/listinfo/zope-dev )
Digital Creations, Publishers of Zope
Zope maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -