From owner-freebsd-hackers  Wed Apr 25 12: 5:12 2001
Delivered-To: freebsd-hackers@freebsd.org
Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67])
	by hub.freebsd.org (Postfix) with ESMTP id AE38337B422
	for <hackers@freebsd.org>; Wed, 25 Apr 2001 12:05:07 -0700 (PDT)
	(envelope-from dillon@earth.backplane.com)
Received: (from dillon@localhost)
	by earth.backplane.com (8.11.2/8.11.2) id f3PJ4xP41049;
	Wed, 25 Apr 2001 12:04:59 -0700 (PDT)
	(envelope-from dillon)
Date: Wed, 25 Apr 2001 12:04:59 -0700 (PDT)
From: Matt Dillon <dillon@earth.backplane.com>
Message-Id: <200104251904.f3PJ4xP41049@earth.backplane.com>
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc: hackers@freebsd.org
Subject: Idea for additional feature for jail - jailed security level
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

    I just had an idea... allow the kernel security level to be specified
    for a jailed environment.  Add a 'securelevel' field to the jail
    structure and bump the API rev.

    The kernel uses the higher of the global securelevel and the securelevel
    defined by the jail when running system calls called from programs running
    in the jail.

    This way we can run at securelevel -1 outside the jail but enforce a
    higher securelevel inside the jail, thus enforcing chflags permissions
    (and other things) within the jail without having to enforce them outside.

    --

    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.

    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.

						-Matt


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message