Dave Jones <davej@redhat.com> wrote:>> On Wed, Jan 12, 2005 at 06:28:38PM -0800, Andrew Morton wrote:> > > IMO, local DoS holes are important mainly because buggy userspace> > applications allow remote users to get in and exploit them, and for that> > reason we of course need to fix them up. Even though such an attacker> > could cripple the machine without exploiting such a hole.> > > > For the above reasons I see no need to delay publication of local DoS holes> > at all. The only thing for which we need to provide special processing is> > privilege escalation bugs.> > > > Or am I missing something?> > The problem is it depends on who you are, and what you're doing with Linux> how much these things affect you.> > A local DoS doesn't both me one squat personally, as I'm the only> user of computers I use each day. An admin of a shell server or> the like however would likely see this in a different light.> (though it can be argued a mallet to the kneecaps of the user> responsible is more effective than any software update)

yup. But there are so many ways to cripple a Linux box once you have localaccess. Another means which happens to be bug-induced doesn't seemimportant.

> An information leak from kernel space may be equally as mundane to some,> though terrifying to some admins. Would you want some process to be> leaking your root password, credit card #, etc to some other users process ?> > priveledge escalation is clearly the number one threat. Whilst some> class 'remote root hole' higher risk than 'local root hole', far> too often, we've had instances where execution of shellcode by> overflowing some buffer in $crappyapp has led to a shell> turning a local root into a remote root.

I'd place information leaks and privilege escalations into their own class,way above "yet another local DoS".

A local privilege escalation hole should be viewed as seriously as a remoteprivilege escalation hole, given the bugginess of userspace servers, yes?