Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753482AbZL3VM4 (ORCPT ); Wed, 30 Dec 2009 16:12:56 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753246AbZL3VMz (ORCPT ); Wed, 30 Dec 2009 16:12:55 -0500 Received: from out01.mta.xmission.com ([166.70.13.231]:45638 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753238AbZL3VMy (ORCPT ); Wed, 30 Dec 2009 16:12:54 -0500 To: "Serge E. Hallyn" Cc: Alan Cox , Benny Amorsen , Bryan Donlan , Michael Stone , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-security-module@vger.kernel.org, Andi Kleen , David Lang , Oliver Hartkopp , Herbert Xu , Valdis Kletnieks , Evgeniy Polyakov , "C. Scott Ananian" , James Morris , Bernie Innocenti , Mark Seaborn , Randy Dunlap , =?utf-8?Q?Am=C3=A9rico?= Wang , Tetsuo Handa , Samir Bellabes , Casey Schaufler , Pavel Machek , Al Viro Subject: Re: RFC: disablenetwork facility. (v4) References: <20091229151146.GA32153@us.ibm.com> <3e8340490912290805s103fb789y13acea4a84669b20@mail.gmail.com> <20091229211139.0732a0c1@lxorguk.ukuu.org.uk> <20091229223631.GB22578@us.ibm.com> <20091230035008.GA6819@us.ibm.com> <20091230180045.GA14493@us.ibm.com> From: ebiederm@xmission.com (Eric W. Biederman) Date: Wed, 30 Dec 2009 13:12:33 -0800 In-Reply-To: <20091230180045.GA14493@us.ibm.com> (Serge E. Hallyn's message of "Wed\, 30 Dec 2009 12\:00\:45 -0600") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-XM-SPF: eid=;;;mid=;;;hst=in01.mta.xmission.com;;;ip=76.21.114.89;;;frm=ebiederm@xmission.com;;;spf=neutral X-SA-Exim-Connect-IP: 76.21.114.89 X-SA-Exim-Mail-From: ebiederm@xmission.com X-SA-Exim-Scanned: No (on in01.mta.xmission.com); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1412 Lines: 42 "Serge E. Hallyn" writes: > Quoting Eric W. Biederman (ebiederm@xmission.com): >> "Serge E. Hallyn" writes: >> >> >> In common cap we drop the new capabilities if we are being ptraced. >> >> Look for brm->unsafe. >> > >> > Yes - that isn't the issue. >> >> Right. Sorry. I saw that we set unsafe and totally >> missed that we don't act on it in that case. >> >> > It goes back to finding a way to figure out what is inside the >> > file when the installer obviously thought we shouldn't be able >> > to read the file. >> > >> > Do we care? >> >> >> >> I expect two lines of testing bprm->unsafe and failing >> at the right point would solve that. > > But what is the right response? Prevent excecution? Stop the > tracer? Enter some one-shot mode where the whole exec appears > as one step, but tracing continues if execution continues on a > dumpable file? The whole exec should already appear as one step. The right response is to either fail the exec or disable the tracer. Since the other case drops privs. I expect failing the exec is the simplest and most consistent thing we can do. Eric -- 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/