From owner-freebsd-hackers Wed Apr 25 12:27:11 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 4F47037B43C for ; Wed, 25 Apr 2001 12:27:04 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3PJQvM41527; Wed, 25 Apr 2001 12:26:57 -0700 (PDT) (envelope-from dillon) Date: Wed, 25 Apr 2001 12:26:57 -0700 (PDT) From: Matt Dillon Message-Id: <200104251926.f3PJQvM41527@earth.backplane.com> To: Poul-Henning Kamp Cc: hackers@freebsd.org Subject: Re: Idea for additional feature for jail - jailed security level References: <74643.988226120@critter> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :In message <200104251904.f3PJ4xP41049@earth.backplane.com>, Matt Dillon writes: :> 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. : :That would be trivial to do, but I thought that securelevels were :demed "nice proof of concept but not the right way" ? : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 Oh, also we would enforce increasing the secure level only... so when you run a jail the minimum securelevel is the current securelevel. And the global sysctl securelevel would still exist and override everything, but now it is possible to leave it at -1 and run most system services (including sshd) at a higher secure level inside a jail, leaving only the init-run getty's running at securelevel -1. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message