Bill Anderson <bill@libc.org> wrote:
Kip Rugger wrote:
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
Would you mind describing how you determine this?
[/proc] $ cat /proc/90/status Name: junkbuster State: S (sleeping) Pid: 90 PPid: 1 Uid: 101 101 101 101 Gid: 101 101 101 101 Groups: 101 <------------------------------ supplemental groups VmSize: 1348 kB VmLck: 0 kB VmRSS: 436 kB VmData: 192 kB VmStk: 84 kB VmExe: 92 kB VmLib: 952 kB SigPnd: 0000000000000000 SigBlk: 0000000000000000 SigIgn: 0000000080011006 SigCgt: 0000000000000000 CapInh: 00000000fffffeff CapPrm: 0000000000000000 CapEff: 0000000000000000 On my machine 101 is uid and gid for nobody; as you can see junkbuster is correctly sandboxed. For unmodified Zope, you'll see a zero in the indicated line (or possibly several values if root belongs to several groups like `wheel' on your system).