"This is why I find the standard security mantra of "disable root logins and use su / sudo" to be extremely silly."
I think you've taken that far too literaly. My understanding of it is to protect against a) brute force retardation b) dumb attackers. Noone said it's supposed to completely protect uid=0. If you're seeing that as "extremely silly" then you're interpreting the recommendation in the wrong way. On Sat, Nov 10, 2012 at 5:06 PM, Michal Zalewski <[email protected]>wrote: > > "Using su to execute commands as an untrusted user from an interactive > > shell may allow the untrusted user to escalate privileges to the user > > running the shell." > > If you have the ability to execute code on that terminal before the > user executes su, it is also possible to simply never allow the real > su application to run until you've already captured the credentials and > escalated to root. For example, you could define an alias or > change PATH in the shell; ptrace the shell or use LD_PRELOAD to change > its semantics; or simply never return to the shell at all, and simply > fake all the subsequent interactions with it (not particularly hard to > do this in a convincing way). > > This is why I find the standard security mantra of "disable root > logins and use su / sudo" to be extremely silly. > > In general, very few OSes are designed to handle such scenarios gracefully. > > /mz > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ >
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
