From owner-freebsd-current@FreeBSD.ORG Sun Feb 5 15:16:46 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 924BC16A420; Sun, 5 Feb 2006 15:16:46 +0000 (GMT) (envelope-from bkoenig@cs.tu-berlin.de) Received: from efacilitas.de (smtp.efacilitas.de [85.10.196.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id F17B243D53; Sun, 5 Feb 2006 15:16:45 +0000 (GMT) (envelope-from bkoenig@cs.tu-berlin.de) Received: from eurystheus.local (port-212-202-169-72.dynamic.qsc.de [212.202.169.72]) by efacilitas.de (Postfix) with ESMTP id 4BEDA4C697; Sun, 5 Feb 2006 16:26:04 +0100 (CET) Received: from [192.168.1.13] (unknown [192.168.1.13]) by eurystheus.local (Postfix) with ESMTP id 4BF505285F; Sun, 5 Feb 2006 16:15:26 +0100 (CET) Message-ID: <43E616EF.9020704@cs.tu-berlin.de> Date: Sun, 05 Feb 2006 16:17:03 +0100 From: =?ISO-8859-1?Q?Bj=F6rn_K=F6nig?= User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Robert Watson References: <43E60708.9000902@cs.tu-berlin.de> <20060205141626.N76666@fledge.watson.org> In-Reply-To: <20060205141626.N76666@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: current@FreeBSD.org Subject: Re: unprivileged users are able to kill certain jailed processes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2006 15:16:46 -0000 Robert Watson schrieb: > On Sun, 5 Feb 2006, [ISO-8859-15] Björn König wrote: > >> unprivileged users of the host environment can see jailed processes >> with the same user ID. Furthermore they are able to send signals to >> these processes. I think since users are not allowed to imprison >> processes there is no reason why they should see them or even kill them. >> >> Someone pointed me to this issue and I want to know what you think >> about this. > > > I recognize the concern, but the current behavior is consistent with the > overall behavior of jail. In attempt to enforce stronger isolation > between the host and the jail, you will run into other, more significant > problems. For example, jail relies on chroot to segment the file system > name space. Since the host environment is typically rooted at the "real" > root, and guest environments are typically chrooted to specific > subtrees, containment is enforced (subject to due care). However, file > system access control isn't aware of jails, so a uid in the host > environment still "owns" files that appear in the chrooted name spaces. > I.e., uid 1000 can edit /home/rwatson/foo, but also > /jail1/home/rwatson/foo if the uid matches. Changing this will be quite > difficult, probably to the point of being undesirable. > > So I guess the question is: if we can't close the file system method of > processes in the host influencing processes in the jail, does it make > sense to, say, control the delivery of signals? You're right. It does not. That means you have to consider that the host environment need to be trustworthy if you use jails and as long as you can't guarantee strict isolation of the host environment from the point of view of unprivileged users it would be the wrong way to obscure jails from these users partially, like I suggested. Thanks for your clarification. Björn