From owner-freebsd-current@FreeBSD.ORG Fri May 21 02:46:13 2004 Return-Path: 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 CC6DC16A4CE; Fri, 21 May 2004 02:46:13 -0700 (PDT) Received: from sev.net.ua (sev.net.ua [212.86.233.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBB1D43D31; Fri, 21 May 2004 02:46:12 -0700 (PDT) (envelope-from shadow@psoft.net) Received: from berloga.shadowland ([213.227.237.65]) by sev.net.ua (8.12.10/8.12.9) with ESMTP id i4L9jvPs018593; Fri, 21 May 2004 12:45:57 +0300 (EEST) (envelope-from shadow@psoft.net) Received: from berloga.shadowland (berloga.shadowland [127.0.0.1]) by berloga.shadowland (8.12.10/8.12.10) with ESMTP id i4L9jvMs009834; Fri, 21 May 2004 12:45:57 +0300 Received: (from root@localhost) by berloga.shadowland (8.12.10/8.12.10/Submit) id i4L9jvmx009832; Fri, 21 May 2004 12:45:57 +0300 From: Alex Lyashkov To: Pawel Jakub Dawidek In-Reply-To: <20040521094119.GB845@darkness.comp.waw.pl> References: <20040520220145.GN4567@genius.tao.org.uk> <20040521080218.GY845@darkness.comp.waw.pl> <20040521090217.GB57989@ip.net.ua> <20040521094119.GB845@darkness.comp.waw.pl> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: PSoft Message-Id: <1085132756.24958.68.camel@berloga.shadowland> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-1) Date: Fri, 21 May 2004 12:45:57 +0300 cc: "freebsd-current@freebsd.org" cc: Ruslan Ermilov 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2004 09:46:13 -0000 =F7 =F0=D4=CE, 21.05.2004, =D7 12:41, Pawel Jakub Dawidek =D0=C9=DB=C5=D4: > On Fri, May 21, 2004 at 12:02:17PM +0300, Ruslan Ermilov wrote: > +> I like the idea of per-jail sysctl MIB trees, e.g.: > +>=20 > +> jail..security.bsd > +>=20 > +> 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.. branch. > +>=20 > +> Inside the jail, jail..security.bsd branch would map to > +> just security.bsd. > +>=20 > +> 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..foo.bar. > +>=20 > +> Whether it's allowed to change a particular sysctl inside > +> a jail is another matter. >=20 > There are two main issues with our current sysctls implementation: > 1. We cannot hide sysctls/sysctl-trees. > 2. We're operating in most cases on integers. >=20 > We can work on 1, but we can't hack 2 easly, we have to transform > sysctls, that have to be treated on per-jail basics from SYSCTL_INT > to SYSCTL_PROC and if so, I'm not sure what for do we need > security.jail. trees then. We can implement them in the same > way security.jail.jailed is impelemented (it shows different value > outside a jail and different inside) and if we want to change it: >=20 > # jexec /sbin/sysctl =3D >=20 > Of course, there could be no /sbin/sysctl utility inside a jail, > but I'll still suggest to add '-j' option to sysctl command to > work just like 'killall -j' (i.e. jail_attach(); sysctl();). killall -j =3D bad idea.. It not kill fork bomb started inside jail. for protect from this situations me must have jail command for stop jail and kill all tasks inside. --=20 Alex Lyashkov PSoft