Re: CVE Request: powerdns does not clear supplementary groups

[Kurt Seifried <kseifried () redhat com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/24/2012 01:10 PM, Miloslav Trmac wrote:
> ----- Original Message -----
> > So what happens when a program starts running as say root, and
> > root has supplemental groups (like "bin" or "daemon" and the
> > program drops its primary user/group but fails to drop
> > supplementary groups, is that a security issue, and is it worthy
> > of a CVE identifier?
> >
> > For most cases I'm going to say probably not (aka no). Having 
> > supplementary groups is intentional and allows permissions to be
> > more fine grained, you can for example make root a member of
> > "logging" so that even when the app drops root privileges would
> > still have the supplementary group of "logging" and can do its
> > logging or whatever.
>
> Yes, the existence of supplementary groups is intentional - but
> that doesn't mean that inheriting supplementary groups is
> intentional.
>
> From the administrator's point of view, the privileges are
> effectively assigned to "the user" as an "atomic" identity - they
> are configured in /etc/passwd and /etc/group _and associated with
> an UID_.  In "ordinary" case, programs running with a specific UID
> are expected to always use the same primary GID, and same primary
> groups.  Yes, the implementation does not match the administrator's
> point of view, the UID, GID and supplementary groups are sparete,
> and , e.g. setuid/setgid may cause a different configuration from
> the "primary" case, or switching privileges temporarily creates
> non-ordinary situations.  Still, I think that keeping the
> administrator's point of view in mind is important.
>
> In the above example, if there really is a "logging" group, and an
> application is configured to drop privileges and switch to uid
> $APP_UID, the administrator would expect that whether the app
> should or should not have the "logging" group membership is
> configured in /etc/groups for $APP_UID, not for root.  So, I can't
> see that as an argument for intentionally not dropping
> supplementary groups. Mirek

Ok I'll admit it, bad example, but I couldn't think of anything better
offhand. Any ways like I said if someone can make a compelling
argument that these should all be security issues that's great, if not
I'll continue to default this to a security hardening issue unless
someone brings up specific instances that need to be dealt with as a
security fix.

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPvpLRAAoJEBYNRVNeJnmTckQQAJM5wgUAeYJlXXiCgkjW+u9/
T/SLE2S/cszH2iCTDYbzoUZOVbd/a92tlM/SEA+OwGt1/0UR4OtTtH99EjU93TzH
ejWOJAzcyM1XRsuttcAbwKnCY7tNRxrBkzxMp8bE2Mdpt+NB3BJhyczpliU1SaRp
5gNAIZK+LnxsTsP7YAlI5dMfFLKcr5UnZEGzJ4M6boNvC6+N6LAIukjLpTGR1kLr
Uwq3YHQj0R4OzyYpaqmuaYbIbF+E9OAp/yrToZ7wyaeEHaXuj4ePd6pm50M/2nP3
/c0lSidCAh7n/5PISFDNg2wn8YN5juhVbUSwgKUM1Bmli2Db5CjyEDHP2Io8WVO2
sLzMHFVSDKdJ5gU7yoeAKxCXTqB7Jc1aUQ7h1IeDtdgIb3eqi+1+m+i7IVbBI0XS
g3ZFAj1DO5idOseaveHSQhIfQpcZq/Ak30LXJULoJqsUkf/KxXNug9uu/8bpW/PY
vluiLaGm+HOhT6YBOOA8Mz8kBlVf4jPw1wovytsChxZ40OXktflII9NaBI9n/8Bd
oJTXg36pbqOrNWlxUSeQRD5rtPfz2nLU7GDqZUvT75evf2FdewboXGxb2Fdx49SR
h/znEa3O5w87YYh2WjxvLqcl45wCmFa9wgj+ZaFPHFtLjXCTllmLIg30RAeUNvxg
uAmGCpqTV+sYbsTRtVnf
=0vyF
-----END PGP SIGNATURE-----