Messages in this thread | | | Date | Wed, 12 Jan 2005 20:49:19 -0800 | From | William Lee Irwin III <> | Subject | Re: thoughts on kernel security issues |
| |
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?
On Wed, Jan 12, 2005 at 10:35:42PM -0500, Dave Jones wrote: > 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)
It deeply disturbs me to hear this kind of talk. If we're pretending to be a single-user operating system, why on earth did we use UNIX as a precedent in the first place?
On Wed, Jan 12, 2005 at 10:35:42PM -0500, Dave Jones wrote: > 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. > For us thankfully, exec-shield has trapped quite a few remotely > exploitable holes, preventing the above.
If we give up and say we're never going to make multiuser use secure, where is our distinction from other inherently insecure single-user OS's?
-- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |