Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752509Ab1BHDnX (ORCPT ); Mon, 7 Feb 2011 22:43:23 -0500 Received: from tundra.namei.org ([65.99.196.166]:40194 "EHLO tundra.namei.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750758Ab1BHDnW (ORCPT ); Mon, 7 Feb 2011 22:43:22 -0500 Date: Tue, 8 Feb 2011 14:43:15 +1100 (EST) From: James Morris To: Kees Cook cc: linux-kernel@vger.kernel.org, Al Viro Subject: Re: [SECURITY] /proc/$pid/ leaks contents across setuid exec In-Reply-To: <20110208011445.GF1457@outflux.net> Message-ID: References: <20110207231416.GD1457@outflux.net> <20110208011445.GF1457@outflux.net> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1001 Lines: 28 On Mon, 7 Feb 2011, Kees Cook wrote: > Sure, I know about O_CLOEXEC, but this is about protecting the > just-been-execed setuid process from the attacking process that has no > reason to set O_CLOEXEC. > > Something like this needs to be enforced on the kernel side. I.e. these > file in /proc need to have O_CLOEXEC set in a way that cannot be unset. > > > Changing the behavior in the core kernel will break userspace. > > I don't think /proc/$pid/* needs to stay open across execs, does it? Or at > least the non-0444 files should be handled separately. Actually, this seems like a more general kind of bug in proc rather than a leaked fd. Each child task should only see its own /proc/[pid] data. - James -- James Morris -- 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/