Bug 722529
| Summary: | Remove root's supplemental groups | |||
|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Steve Grubb <sgrubb> | |
| Component: | setup | Assignee: | Ondrej Vasik <ovasik> | |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
| Severity: | high | Docs Contact: | ||
| Priority: | high | |||
| Version: | rawhide | CC: | security-response-team | |
| Target Milestone: | --- | Keywords: | Security | |
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | setup-2.8.36-1.fc16 | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 724007 (view as bug list) | Environment: | ||
| Last Closed: | 2011-08-23 20:24:41 UTC | Type: | --- | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 724007 | |||
Thanks for the report and suggestion, Steve ... this is probably impossible to fix this (other than some post lua scriptlet) by setup update - only by clean installation. Do you plan to report this against RHEL-6 as well? The only think I'm wondering about is the historical purpose of these root's suplementary groups. Are the reasons for these groups completely gone and simple removal safe ? I put this in the same category as when we changed the default password hash to sha512. No nice way to fix old installs, so we have release notes that tell admins what to do (that's why I put the usermod instructions above). New installs are correct from the beginning. I've heard other distributions don't have supplemental groups for root by default. I don't run other distros, but I heard it from a very reliable source. As best I can determine, they were like this from the dawn of time no one ever considered it. Bill said this goes back at least to RHL 5.2. Which probably predates CAP_DAC_OVERRIDE. At this point, capabilities should let root go wherever it needs to go. I looked at a Debian livecd. It has no supplemental groups at all except one called user to grant access to multimedia devices it seems. Maybe we should clean up more than just root. Bin, daemon, adm probably do not need to be in each other's groups, for example. And groups do not need their own group as a supplemental group. For example, lp has lp in its supplemental groups. This is unneccesary. I think there is one or two more like this. setup-2.8.36-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/setup-2.8.36-1.fc16 (In reply to comment #9) > setup-2.8.36-1.fc16 has been submitted as an update for Fedora 16. > https://admin.fedoraproject.org/updates/setup-2.8.36-1.fc16 This does not really fall into a category we call security update, imo. I filed the update only as a bugfix update, probably bodhi changed this automatically based on the Security keyword, I don't know ... anyway, as it is before f16 beta, it doesn't really matter that much... Package setup-2.8.36-1.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing setup-2.8.36-1.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/setup-2.8.36-1.fc16 then log in and leave karma (feedback). (In reply to comment #11) > I filed the update only as a bugfix update, probably bodhi changed this > automatically based on the Security keyword, I don't know ... anyway, as it is > before f16 beta, it doesn't really matter that much... Ah, bodhi magic, right... setup-2.8.36-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. |
Description of problem: The root account has: root, bin, sys, daemon, disk, and wheel as supplemental groups. This means that if code does this: if (setgid(id) || setuid(id) ) { exit(1); } it possibly leaves supplemental groups attached to the process. Because most code does not yet use file system based capabilities, the vast majority of code that can do this sequence is the root user - which has supplemental groups. Any other exploitable condition in such programs means the supplemental groups make the attack more severe. One simple solution is to remove root from all entries in the 4th column of /etc/group. It should be noted that setuid root programs are immune to this problem because initgroups is not called which would have added the supplemental groups. Additional info: usermod -G "" root can be used after upgrade to produce the same results.