From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261452AbVAMDoh (ORCPT ); Wed, 12 Jan 2005 22:44:37 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261407AbVAMDog (ORCPT ); Wed, 12 Jan 2005 22:44:36 -0500 Received: from fw.osdl.org ([65.172.181.6]:50576 "EHLO mail.osdl.org") by vger.kernel.org with ESMTP id S261425AbVAMDng (ORCPT ); Wed, 12 Jan 2005 22:43:36 -0500 Date: Wed, 12 Jan 2005 19:42:39 -0800 From: Andrew Morton To: Dave Jones Cc: torvalds@osdl.org, marcelo.tosatti@cyclades.com, greg@kroah.com, chrisw@osdl.org, alan@lxorguk.ukuu.org.uk, linux-kernel@vger.kernel.org Subject: Re: thoughts on kernel security issues Message-Id: <20050112194239.0a7b720b.akpm@osdl.org> In-Reply-To: <20050113033542.GC1212@redhat.com> References: <20050112094807.K24171@build.pdx.osdl.net> <20050112185133.GA10687@kroah.com> <20050112161227.GF32024@logos.cnet> <20050112205350.GM24518@redhat.com> <20050112182838.2aa7eec2.akpm@osdl.org> <20050113033542.GC1212@redhat.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Dave Jones 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 local access. Another means which happens to be bug-induced doesn't seem important. > 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 remote privilege escalation hole, given the bugginess of userspace servers, yes?