Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964886AbWBPTjA (ORCPT ); Thu, 16 Feb 2006 14:39:00 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964884AbWBPTjA (ORCPT ); Thu, 16 Feb 2006 14:39:00 -0500 Received: from e5.ny.us.ibm.com ([32.97.182.145]:3202 "EHLO e5.ny.us.ibm.com") by vger.kernel.org with ESMTP id S964882AbWBPTi7 (ORCPT ); Thu, 16 Feb 2006 14:38:59 -0500 Subject: Re: (pspace,pid) vs true pid virtualization From: Dave Hansen To: Herbert Poetzl Cc: "Eric W. Biederman" , "Serge E. Hallyn" , Kirill Korotaev , linux-kernel@vger.kernel.org, vserver@list.linux-vserver.org, Alan Cox , Arjan van de Ven , Suleiman Souhlal , Hubertus Franke , Cedric Le Goater , Kyle Moffett , Greg , Linus Torvalds , Andrew Morton , Greg KH , Rik van Riel , Alexey Kuznetsov , Andrey Savochkin , Kirill Korotaev , Andi Kleen , Benjamin Herrenschmidt , Jeff Garzik , Trond Myklebust , Jes Sorensen In-Reply-To: <20060216191245.GA28223@MAIL.13thfloor.at> References: <20060215145942.GA9274@sergelap.austin.ibm.com> <20060216143030.GA27585@MAIL.13thfloor.at> <1140111692.21383.2.camel@localhost.localdomain> <20060216191245.GA28223@MAIL.13thfloor.at> Content-Type: text/plain Date: Thu, 16 Feb 2006 11:38:13 -0800 Message-Id: <1140118693.21383.18.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2492 Lines: 67 On Thu, 2006-02-16 at 20:12 +0100, Herbert Poetzl wrote: > On Thu, Feb 16, 2006 at 09:41:32AM -0800, Dave Hansen wrote: > > Giving admin processes the ability to enter pid spaces seems like it > > solves an entire class of problems, right?. > > really depends on the situation and the setup. > let me give a few examples here (I'll assume > fully blown guests not just pid spaces here) > > - guest is running some kind of resource hog, > which already reached the given guest limits > > any attempt to enter the guest will fail > because the limits do not permit that > > - the guest has been suspended (unscheduled) > because of some fork bomb running inside > and you want to kill off only the bomb > > entering the guest would immediately stop > your process, so no way to send signals > > - there is a pid killer running inside the > guest, which kills every newly created > process as soon as it is discovered > > entering the guest would kill your shell Brainstorming ... what do you think about having a special init process inside the child to act as a proxy of sorts? It is controlled by the parent vserver/container, and would not be subject to resource limits. It would not necessarily need to fork in order to kill other processes inside the vserver (not subject to resource limits). It could also continue when the rest of the guest was suspended. A pid killer would be ineffective against such a process because you can't kill init. > > Could you explain a bit what kinds of security issues it introduces? > > well, it introduces a bunch of issues, not all > directly security related, here some of them: > (I keep them general because most of them can > be worked around by additional checks and flags) > > - ptrace from inside the context could hijack > your 'admin' task and use it for all kind > of evil stuff You can't ptrace init, right? > In general, I prefer to think of this as working > with nuclear material via an actuator from behind > a 4" lead wall -- you just do not want to go in > to fix things :) Where does that lead you? Having a single global pid space which the admin can see? Or, does a special set of system calls do it well enough? -- Dave - 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/