Date: Thu, 26 Apr 2001 01:33:55 +0400 (MSD) From: .@babolo.ru To: dillon@earth.backplane.com (Matt Dillon) Cc: phk@critter.freebsd.dk, hackers@FreeBSD.ORG Subject: Re: Idea for additional feature for jail - jailed security level Message-ID: <200104252133.BAA05985@aaz.links.ru> In-Reply-To: <200104251904.f3PJ4xP41049@earth.backplane.com> from "Matt Dillon" at "Apr 25, 1 12:04:59 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Matt Dillon writes: ..... > Idea #2: There are a number of sysctl's that effect jails globally, > such as jail_sysvipc_allowed. > > Encapsulate these parameters in an internal named kernel structure and > provide system calls to set and retrieve the parameters. e.g. > > int jail_param(int jailset, int cmd, int type, int value) > > cmd: JAIL_GET_PARAM or JAIL_SET_PARAM > type: e.g. JAIL_TYPE_SYSVIPC_DISABLE > value: e.g. 0 or 1 (if setting), unused if retrieving. > > Then allow the 'jailset' id to be specified in the jail() system call, > allowing you to customize the sysctl parameters for any given jail. > The least permissive of the global sysctl defaults and the jailset > parameters would be used within the jail so you can still globally > disable something in a running system. And add jailset column to ps(1) (-o ?) and programm, similar to kill(1) or killall(1) with jailset parameter. And, of cause, jail(1) must print off jailset > jail_param() would be disabled within a jail or when running at > a securelevel other then -1. Combined with the first idea this > would allow the system admin (outside the jail) to manipulate the > jail parameters of jailed users running inside jails on the system. -- @BABOLO http://links.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104252133.BAA05985>