|Summary:||CVE-2009-3564 puppetmasterd does not initialize supplementary groups|
|Product:||[Other] Security Response||Reporter:||Till Maas <opensource>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||CLOSED WONTFIX||QA Contact:|
|Version:||unspecified||CC:||bressers, iboverma, k.georgiou, lutter, matt, maurizio.antillon, mjc, opensource, tmz, vanmeeuwen+fedora, vdanen|
|Target Milestone:||---||Keywords:||Reopened, Security|
|Fixed In Version:||0.24.8-4.el4||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2011-07-25 19:45:08 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Till Maas 2008-12-08 14:27:45 UTC
Description of problem: I noticed that puppetmasterd does not initialize its supplementary groups, which may lead to allow puppetmasterd to access files, it should not. E.g. if it is started with "service puppetmaster start", it still has access to all files that allow read access for the supplementary groups of root, e.g. raw disk devices. I filed an upstream bug report including patches (one needs still to be tested) here: http://projects.reductivelabs.com/issues/show/1806 Version-Release number of selected component (if applicable): puppet-0.24.6-1.fc10 puupet-0.24.6-1.el5 How reproducible: always Steps to Reproduce: 1. # service puppetmaster start 2. # cat /proc/$(ps --User puppet -o pid | tail -n 1)/status | grep Group Actual results: The output matches "id -G root". Expected results: The output should match "id -G puppet", i.e. the process should run with the supplementary groups of puppet. The default supplementary groups of root include the group disk, which e.g. provides raw read access on disk devices. Additional info: I am not sure, whether this really classifies as a security vulnerability, because https://fedoraproject.org/wiki/Security/Classifications only mentions code execution and denial of service, but imho unwanted access to restricted information is a security vulnerability, too.
Comment 1 Fedora Admin XMLRPC Client 2009-03-16 16:52:15 UTC
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Comment 2 Jeroen van Meeuwen 2009-06-24 14:07:53 UTC
Pending upcoming release, a great deal of thanks!
Comment 3 Fedora Update System 2009-08-10 15:04:02 UTC
puppet-0.24.8-4.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/puppet-0.24.8-4.fc10
Comment 4 Fedora Update System 2009-08-10 15:04:27 UTC
puppet-0.24.8-4.el5 has been submitted as an update for Fedora EPEL 5. http://admin.fedoraproject.org/updates/puppet-0.24.8-4.el5
Comment 5 Fedora Update System 2009-08-10 15:04:51 UTC
puppet-0.24.8-4.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/puppet-0.24.8-4.fc11
Comment 6 Fedora Update System 2009-08-10 15:05:16 UTC
puppet-0.24.8-4.el4 has been submitted as an update for Fedora EPEL 4. http://admin.fedoraproject.org/updates/puppet-0.24.8-4.el4
Comment 7 Fedora Update System 2009-09-11 23:23:41 UTC
puppet-0.24.8-4.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
Comment 8 Fedora Update System 2009-09-11 23:36:29 UTC
puppet-0.24.8-4.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
Comment 9 Fedora Update System 2009-09-12 17:51:49 UTC
puppet-0.24.8-4.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
Comment 10 Fedora Update System 2009-09-12 17:53:23 UTC
puppet-0.24.8-4.el4 has been pushed to the Fedora EPEL 4 stable repository. If problems still persist, please make note of it in this bug report.
Comment 11 Till Maas 2009-10-06 08:03:47 UTC
There is now a CVE number assigned for this issue, the metadata for the repositories should probably be updated. The number is: CVE-2009-3564
Comment 12 Vincent Danen 2009-10-07 16:53:34 UTC
Re-opening as this issue also affects Red Hat Enterprise MRG 1.1. The Red Hat Security Response Team has rated this issue as having low security impact, a future update may address this flaw.
Comment 17 Josh Bressers 2011-07-25 19:45:08 UTC
Statement: The Red Hat Security Response Team does not currently plan to fix this flaw in MRG.