Bug 601955 (CVE-2010-2198)
| Summary: | CVE-2010-2198 rpm: fails to drop POSIX file capabilities on package upgrade or removal | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Vincent Danen <vdanen> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | dwalsh, ffesti, jdmi, jnovy, matt, mschmidt, pmatilai |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-08-20 11:09:10 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: | |||
|
Description
Vincent Danen
2010-06-08 22:43:20 UTC
See bug #598775 for an initial description and comments of this issue. Because different CVE names were assigned for different, yet related, issues, a separate bug has been filed for this particular issue. Does "SELinux context information" on an executable allow it to be run with privileges that are in any way elevated from what the user could otherwise achieve? Someone familiar with SELinux will have to answer this. rpm-4.8.1-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/rpm-4.8.1-1.fc13 (In reply to comment #2) > Does "SELinux context information" on an executable allow it to be run with > privileges that are in any way elevated from what the user could otherwise > achieve? Someone familiar with SELinux will have to answer this. CC'ing dwalsh for comments/corrections but AFAIK: SELinux can be only used to further restrict permissions beyond what a user would otherwise be allowed to do. Hardlinked files "inherit" the security context of the target, so they are subject to the similar issues as capabilities and suid/sgid in a sense. Say you have an essentially unconfined binary in package foo, and you make a hardlink to that file to "stash it". If package foo is updated (to break the hardlink), and then a policy update brings a different policy and/or context for that binary, you /might/ now have a less restricted binary at your disposal. Or it might be a completely broken binary as the policy prevents the binary with old context from doing what it needs to do. Or something else. But this wont give you any extra permissions you wouldn't have on a non-selinux system. Also SELinux contexts cannot be "dropped", somewhat like you can't "drop" the uid and gid of a file; you can only change it to something else assuming you have sufficient privileges to do so. Unless SELinux has a built-in (ie doesn't depend on any particular policy being loaded) or otherwise run-time discoverable "deny everything" context which rpm could use to "drop" contexts to on upgrade/remove, there's not much rpm can do about it. (In reply to comment #4) > Also SELinux contexts cannot be "dropped", somewhat like you can't "drop" the > uid and gid of a file; you can only change it to something else assuming you > have sufficient privileges to do so. Unless SELinux has a built-in (ie doesn't > depend on any particular policy being loaded) or otherwise run-time > discoverable "deny everything" context which rpm could use to "drop" contexts > to on upgrade/remove, there's not much rpm can do about it. "default_t" might be a good candidate. See http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Working_with_SELinux-The_file_t_and_default_t_Types.html But it would be even better if there were a context which even unconfined_t could not access. unconfined means unconfined. If you want to confine a user then use staff_u or some other confined user. SELinux context on a file might allow an application to transition do a different domain (process label) This label could have different access then the original process. Maybe more/Maybe less/ Maybe a combo of both. SELinux should not give any more access then if it was disabled. So it only further restricts on privs of DAC. Statement: Not vulnerable. RPM as provided with Red Hat Enterprise 3, 4, and 5 do not support POSIX capabilities. Removing the SELinux context part as it's doesn't give elevated privileges in the sense that SUID/SGID/capabilities do. Also SELinux context cannot be similarly dropped, only changed, and rpm has no way of knowing whether some other context would be "more secure" than the one a given file to be unlinked/replaced currently has. rpm-4.7.2-2.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/rpm-4.7.2-2.fc12 rpm-4.7.2-2.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report. rpm-4.8.1-2.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. |