From owner-freebsd-hackers Wed Apr 25 12:23:48 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 A44B537B422 for ; Wed, 25 Apr 2001 12:23:45 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3PJNcD41451; Wed, 25 Apr 2001 12:23:38 -0700 (PDT) (envelope-from dillon) Date: Wed, 25 Apr 2001 12:23:38 -0700 (PDT) From: Matt Dillon Message-Id: <200104251923.f3PJNcD41451@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 Here's my thinking: Right now we have this wonderful 'securelevel' feature which, if turned on, allows us to enforce chflags permissions. The only problem with it is that in order to make chflags permissions effective, we have to pretty much use them on every file in the system (not just 'strategic' files). This makes systems difficult to maintain without taking down. At BEST we tried to use securelevel and, in fact, did, but in order to change anything without taking the box down we had to break into DDB and turn it off temporarily, make the changes, then raise it again. At home and on Backplane machines it's just too inconvenient, yet I still would love most of the services and logins to those machines to run at a higher securelevel if I could. But if we have the ability to run at a higher securelevel inside a jail we can allow console-root logins to access the system at the global securelevel of -1 yet force every single other login to the system and *ALL* services to run inside a jail (chroot to "/" essentially) with a higher securelevel. Enforcing the securelevel combined with the use of chflags inside a prison, plus idea #2, gives us much more flexibility then the hardwired restrictions jail() currently employs. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message