Bug 1218672 (CVE-2015-3170)
Summary: | CVE-2015-3170 selinux-policy: policy package update causes denial of service | ||
---|---|---|---|
Product: | [Other] Security Response | Reporter: | Martin Prpič <mprpic> |
Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
Status: | CLOSED WONTFIX | QA Contact: | |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | unspecified | CC: | dominick.grift, dwalsh, fweimer, jpazdziora, kdudka, lvrabec, mgrepl, mmalik, plautrba, pvrabec, scorneli, ssekidde, tmraz |
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: | 2016-06-15 09:24:45 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: | 1225782 |
Description
Martin Prpič
2015-05-05 14:06:45 UTC
Yes and this is a reason why you would not use hardlinks. restorecon is not able to tell you about multiple hard links with conflicting matches. Not sure if we still need to have restorecon calling if we have filename transitions rules. How would you create the hardlink without fs.protected_hardlinks=0 ? You can still shoot your own foot as root but as a regular user you could not create the hardlink. (In reply to Tomas Mraz from comment #2) > How would you create the hardlink without fs.protected_hardlinks=0 ? As far as I know, we still support running with fs.protected_hardlinks=0. Even with protected hardlinks, this bug is still there, it is just more difficult to demonstrate that it is bad. One change would be to only allow restorecon/setfiles on files with out links. And require -f to override this. Do we have a list of know linked files? (In reply to Daniel Walsh from comment #4) > One change would be to only allow restorecon/setfiles on files with out > links. And require -f to override this. > > Do we have a list of know linked files? I'm not aware of such a list. Florian stated: "This is a property of the customer file system. We don't know what will be there.". That makes sense to me - so I guess relying on a list is not the path to go. I am thinking if we had a known list of linked files in the distribution, then we could allow restorecon to relabel those, or at least check to make sure they have the same label, when it finds one. I think the only way to prevent the customer having links problem is to not fix labels by default on multi-linked files. I believe in the latest kernel we can prevent users from Hard Linking to files that are not owned by the user, which adds some protection. Another useful input from Florian; "The full fix involves opening files with O_PATH and checking that the link count is 1 before changing their file context. This is not possible with the glibc file traversal helper being used, so it requires major surgery on the code (but it's still doable as a security update)." Do you think you can rework the code? Statement: Red Hat Product Security has rated this issue as having Low security impact. This issue is not currently planned to be addressed in future updates. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/. |