From owner-freebsd-current@FreeBSD.ORG  Fri May 21 02:10:57 2004
Return-Path: <owner-freebsd-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 67B3B16A4CE; Fri, 21 May 2004 02:10:57 -0700 (PDT)
Received: from relay.macomnet.ru (relay.macomnet.ru [195.128.64.10])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 5566B43D39; Fri, 21 May 2004 02:10:56 -0700 (PDT)
	(envelope-from maxim@macomnet.ru)
Received: from mp3 (mp3files.int.ru [195.128.64.20])
	by relay.macomnet.ru (8.12.10/8.12.10) with ESMTP id i4L9Asu514523918;
	Fri, 21 May 2004 13:10:54 +0400 (MSD)
Date: Fri, 21 May 2004 13:10:49 +0400 (MSD)
From: Maxim Konovalov <maxim@macomnet.ru>
To: Ruslan Ermilov <ru@freebsd.org>
In-Reply-To: <20040521090217.GB57989@ip.net.ua>
Message-ID: <20040521131013.B17083@mp3files.int.ru>
References: <20040520220145.GN4567@genius.tao.org.uk>
	<20040521081419.GB89262@cell.sick.ru>
	<20040521090217.GB57989@ip.net.ua>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
cc: Josef Karthauser <joe@freebsd.org>
cc: Gleb Smirnoff <glebius@cell.sick.ru>
cc: freebsd-current@freebsd.org
cc: Pawel Jakub Dawidek <pjd@freebsd.org>
Subject: Re: Call for a hacker.... security.bsd.see_other_uids in jails only
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 21 May 2004 09:10:57 -0000

On Fri, 21 May 2004, 12:02+0300, Ruslan Ermilov wrote:

> On Fri, May 21, 2004 at 12:14:19PM +0400, Gleb Smirnoff wrote:
> > On Fri, May 21, 2004 at 10:02:18AM +0200, Pawel Jakub Dawidek wrote:
> > P> Implementation wouldn't be probably too hard, but I can't agree it should
> > P> be committed. We need to know where jail's virtualization ends and I think
> > P> it is too far. Of course it will be cool to have those sysctl on per-jail
> > P> basics, as well as others from security.bsd. tree
> > P> (like security.bsd.suser_enabled), but I'm not sure this is the right way
> > P> to go.
> > P>
> > P> Any other opinions? If someone convince me we should do it, I can do it.
> >
> > A more general solution will be better, but harder to implement: make
> > some sysctl branches (e.g. security.bsd) local per jail, and possibility to
> > change them only from host machine.
> >
> I like the idea of per-jail sysctl MIB trees, e.g.:
>
> jail.<JID>.security.bsd
>
> When jail gets created, the generic sysctl code would traverse
> the primary sysctl tree (excluding the jail. subtree), and copy
> and attach those that have some jail-related flag to the
> jail.<JID>. branch.
>
> Inside the jail, jail.<JID>.security.bsd branch would map to
> just security.bsd.
>
> The generic sysctl code, when it detects it's run within a
> jail, will find a sysctl node "foo.bar", and if it has a
> jail-clone flag set, will remap a query to jail.<JID>.foo.bar.
>
> Whether it's allowed to change a particular sysctl inside
> a jail is another matter.

We are discovering vimage slowly :-)

http://www.tel.fer.hr/zec/BSD/vimage/

-- 
Maxim Konovalov