On 4 Sep 2000 rugger@pangea.ca 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 know... Thanks, C
Chris McDonough <chrism@digicool.com> 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 - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Chris McDonough Digital Creations, Publishers of Zope http://www.zope.org