Comment 15 for bug 634183
Revision history for this message
|
|
#15 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
(In reply to comment #11)
> Creating a hardlink (in most cases for RPM managed files) assumes privilege
> that makes any other escalation vector through hardlinks to "previously
> RPM-manged"
> files moot.
How? Please be specific.
I agree that it would be highly desirable to block the hard-linking, but that is a moot point because the attack does not actually require hard links, as I noted in bug 589775 comment #25.
> You might well report the same problems against rm(1) since the same
> system call unlink(2) is unaware of unknown persistent side effects if/when
> an additional hardlink has been created.
In principle, you are right. However, I think it's reasonable to start with RPM because it is by far the most frequent unlinker of privileged executables on Fedora. (As an anecdote, when I realized a custom program I was writing for my system would require a setuid wrapper, my gut feeling told me I should install it with RPM rather than manually in /usr/local, even though I was unaware of this issue at the time.) Addition of a --clear-caps option to the relevant coreutils can be considered in a separate bug.
> There are -- in fact -- no escalations of note reported for any of the (2? or
> is it 3 now?)
> CVE's being reported against RPM.
Maybe not against RPM, but the Debian bug I cited in bug 589775 comment #0 linked to a report of the attack being performed against dpkg:
http://