From owner-freebsd-virtualization@FreeBSD.ORG Wed Jun 18 21:04:21 2008 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13CF8106566C for ; Wed, 18 Jun 2008 21:04:21 +0000 (UTC) (envelope-from zec@icir.org) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.freebsd.org (Postfix) with ESMTP id 9156E8FC18 for ; Wed, 18 Jun 2008 21:04:20 +0000 (UTC) (envelope-from zec@icir.org) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id 4536E9B64E; Wed, 18 Jun 2008 23:04:19 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [192.168.200.112] (zec2.tel.fer.hr [161.53.19.79]) by xaqua.tel.fer.hr (Postfix) with ESMTP id 16C499B649; Wed, 18 Jun 2008 23:04:17 +0200 (CEST) From: Marko Zec To: James Gritton Date: Wed, 18 Jun 2008 23:03:56 +0200 User-Agent: KMail/1.9.7 References: <48588595.7020709@gritton.org> <200806182156.37998.zec@icir.org> <48596B1D.8000801@gritton.org> In-Reply-To: <48596B1D.8000801@gritton.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806182303.57184.zec@icir.org> Cc: freebsd-virtualization@freebsd.org Subject: Re: V_* meta-symbols and locking X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 21:04:21 -0000 On Wednesday 18 June 2008 22:07:57 James Gritton wrote: > Marko Zec wrote: > >>> The only thing I'd like to have > >>> as an option is to be able to spawn a new process in the target > >>> VM _without_ making it chrooted... > >> > >> If you mean creating a jail that's not chrooted, that's no > >> problem. If you mean creating a jail that *is* chrooted, and then > >> placing a process into that jail without chrooting it, that would > >> be a breakage of the jail paradigm. Hopefully you mean the > >> former? > > > > No, I want the later, as an option. Given that the parent > > environment / jail completely controls the child anyhow, I don't > > think such an (optional) behavior would be too big a security > > issue. > > I'm thinking of the security implications, but of the mess. The > existing jail_attach() wouldn't be sufficient, as it only passes a > jid. You'd need a separate jail_attach2() sysctl call. Would this > be exactly the same as jail_attach() except that it doesn't do the > chroot? That sounds like a one-off to me. So would you instead have > a way of specifying which parts of the jail environment you do and > don't want? Then you'd have to not only know what virtualizations a > jail does and doesn't do (the problem I'm working on), but also what > virtualizations every process in a jail may or may not have enabled. > It might be that only the chroot can reasonable support this kind of > split anyway. > > Why do you want this? If you want to be part of the jail, you attach > to it. If you want to do administration of the jail environment, it > should be sufficient to do it from outside. Consider a situation where the directory tree of a jail would get corrupted or compromised (by accident or maliciously), so that you couldn't or wouldn't wish to exec any binaries from that part of the filesystem tree, but you'd like to check the network state / setup there (TCP connections, routes, firewall...), perhaps do a tcpdump capture and store it in a file inaccessible to processes already running in that jail... Marko