From owner-freebsd-security Sun Jun 20 13:19:42 1999 Delivered-To: freebsd-security@freebsd.org Received: from beach.silcom.com (beach.silcom.com [199.201.128.19]) by hub.freebsd.org (Postfix) with ESMTP id 0FF8115049; Sun, 20 Jun 1999 13:19:35 -0700 (PDT) (envelope-from brian@CSUA.Berkeley.EDU) Received: from smarter.than.nu (pm0-17.vpop1.avtel.net [207.71.237.17]) by beach.silcom.com (Postfix) with ESMTP id E4E3D5D5; Sun, 20 Jun 1999 13:19:31 -0700 (PDT) Date: Sun, 20 Jun 1999 13:19:31 -0700 (PDT) From: "Brian W. Buchanan" X-Sender: brian@smarter.than.nu To: Eivind Eklund Cc: FreeBSD-security Mailing List Subject: Re: proposed secure-level 4 patch In-Reply-To: <19990620180356.J63035@bitbox.follo.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 20 Jun 1999, Eivind Eklund wrote: > On Sat, Jun 19, 1999 at 12:56:19AM -0500, Frank Tobin wrote: > > Okay, a good friend of mine Kris Wehner has written a patch to implement > > the proposed securelevel of 4, which would disallow the opening of > > secure ports (<1024) while in the securelevel of 4. The patch is against > > 3.2-STABLE kernel, as of within 12 hours. I'd like to hear more comments > > before I send it as a send-pr. The patch is attached. > > I think using securelevel 4 for this is a bad idea. I believe the > right thing to do with securelevels is to start splitting them into a > set of different sysctls, where each individual feature can be turned > off. It is convenient to have a set of sysctls you can use to "turn > off everything" (like securelevel does today). > > However, to apply a "full securelevel" to a box is difficult; the > ability to throw away single capabilities could be very useful. I considered suggesting this last night, then realized that applying only the effect added by securelevel 3 or the proposed level 4 would be ineffective, as it's easily circumvented through loading a custom kernel module, writing to /dev/kmem, etc. Blocking the binding of low ports would be ineffective without restrictions on changing IPFW rules, as IIRC IPFW rules can be used to redirect packets from one port to another. For what we have now and for the proposed securelevel 4, I'd say that the current system makes sense. If we did start to add security features that are orthogonal to the present ones, however, I'd agree that they should be separate sysctl knobs. Securelevel 2 would still be pretty much mandatory for enforcing any other restrictions on root, though. -- Brian Buchanan brian@CSUA.Berkeley.EDU -------------------------------------------------------------------------- FreeBSD - The Power to Serve! http://www.freebsd.org daemon(n): 1. an attendant power or spirit : GENIUS 2. the cute little mascot of the FreeBSD operating system To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message