Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4FBE808A.9060004@redhat.com>
Date: Thu, 24 May 2012 12:40:10 -0600
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security@...ts.openwall.com
CC: 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

CC'ing the PowerDNS guys.

On 05/24/2012 10:20 AM, David Black wrote:
> Powerdns does not drop/clear supplementary groups in its dropPrivs 
> routine where the intent is to drop privileges.
> 
> The relevant code can be found in pdns/unix_utility.cc / 
> pdns-recursor-3.3/unix_utility.cc [0].
> 
> Can a CVE id be assigned for this issue?
> 
> 
> [0] pdns/unix_utility.cc / pdns-recursor-3.3/unix_utility.cc //
> Drops the program's privileges. void Utility::dropPrivs( int uid,
> int gid ) { if(gid) { if(setgid(gid)<0) { 
> theL()<<Logger::Critical<<"Unable to set effective group id to 
> "<<gid<<": "<<stringerror()<<endl; exit(1); } else 
> theL()<<Logger::Info<<"Set effective group id to "<<gid<<endl;
> 
> }
> 
> if(uid) { if(setuid(uid)<0) { theL()<<Logger::Critical<<"Unable to
> set effective user id to "<<uid<<":  "<<stringerror()<<endl; 
> exit(1); } else theL()<<Logger::Info<<"Set effective user id to
> "<<uid<<endl; } }


So the dropping of groups and the dropping of supplementary groups has
come up a lot recently, here are my personal thoughts on the matter
(with thanks to Steve Grubb for explaining some of the trickier bits).
These are of course my personal opinions, any mistakes/errors are mine
entirely and so on.

Dropping of the primary user and group privileges is a well known
security feature in many programs (e.g. bind, dhcp, apache, etc.). The
idea being programs need root to bind to privileged ports/etc. But
once done don't need root access. I think clearly in this case if a
program is running as root, and claims to give up root privileges but
fails to, that is a security issue and worthy of a CVE. In the case
where a program does NOT drop privileges, and this feature has now
been added (and assuming it works), I think this qualifies as security
hardening, not a security fix and NOT worthy of a CVE.

Now it gets messy. What about the dropping of supplementary groups?

Supplemental groups enabled a user to be a member of more than one
group at a time (us old timers remember the joys of "newgrp"). Why
would anyone want this? You could for example create a group that has
permissions to access logging, terminals (e.g. modems, remember those?
=) and then add users to it as appropriate (and centralize
account/permissions management somewhat and all that good stuff).

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.

So unless someone makes a compelling argument that these are security
issues I'm going to err on the side of "security hardening" instead of
"security fix" for dropping supplementary groups, but of course not
all issues are the same so if you have a specific issue and think it
deserves a CVE make a case on OSS-sec.

* Should these issues be fixed? yes. Dropping privileges where
possible is usually a good idea, until things break though and then
people start disabling things like SELinux or running everything as
root to "make it work" :P.

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

iQIcBAEBAgAGBQJPvoCKAAoJEBYNRVNeJnmT0NoP/0klqbji/ArTnVauB9U895Ye
F8ck9XjRjdxTkmqSZB2rQiD2fmENkHFdZrmG8Vh8BLlnTreamOGwOiPIvX2dkGrM
zDLoWbFVWD2ORGL7zUBL8KgJ3TkHsiXwGO0N7ojW7pun2S9HsWWtjIK2p0S/cjV+
rJAUg0vXeQ3d/ySzYNSuUIiyPFFYRMjNV4m35lTFwVz33d+hq9t6cf0JKzJLyH4h
uqvhdOsYYrh4UOTkxSzdnWovtxsK16yvGrMFpa3N+4FGgqvlhDhwSvFj2aVWKy0I
zQS1PpvJJiWfYzPRweze82yHLS22owmXBYl4Tl6igJB7l3v/uIzQJeExF+CWPTMB
ZUdODKiDNd+jFqOUJcvrX0HJn1f/KJmNf11EdW3VZBrOpgKSLQUDJ43+RSGSDF6E
tHfub3L1pZ4SbDXFVPzvlCzIsUkWhB8h3WwkTTZV2HbLdFiDDaInEH8wfwymc+2N
YFvj+rjDj5dwftoTwutE92ElcCX8cpI51MqnvyaPChQCe1XdoF+wbM/+byyZHXZf
tm/d19d/6Tjm7JmLIDfMWKFbGq8dJkuKjK4n2qZgqImd+2E1e2iLGB68pQvRDcgl
BxGNlj1PL4THwkjMwjtO9s32JMlFcDYM3MjCt7GOSCOU9HyD7nNER10cH3oJ5n3S
1jkfJxJyNMowHJx3/nJH
=6ZUw
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists

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.