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 -