oss-security - Re: CVE Request: powerdns does not clear supplementary groups

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4FBE92D1.9060905@redhat.com>
Date: Thu, 24 May 2012 13:58:09 -0600
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security@...ts.openwall.com
CC: Miloslav Trmac <mitr@...hat.com>, David Black <disclosure@....org>,
        Peter van Dijk <peter.van.dijk@...herlabs.nl>,
        Bert Hubert <bert.hubert@...herlabs.nl>
Subject: Re: CVE Request: powerdns does not clear supplementary
 groups

-----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-----

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.