From owner-freebsd-hackers Tue Jul 27 9:51:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 7BDBF14D0E for ; Tue, 27 Jul 1999 09:51:35 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA54626; Tue, 27 Jul 1999 09:48:30 -0700 (PDT) (envelope-from dillon) Date: Tue, 27 Jul 1999 09:48:30 -0700 (PDT) From: Matthew Dillon Message-Id: <199907271648.JAA54626@apollo.backplane.com> To: Sheldon Hearn Cc: hackers@FreeBSD.ORG Subject: Re: securelevel too course-grained? References: <87126.933053846@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> Subject: Re: securelevel and ipfw zero :> :> However, it does not allow you to do it if you are sitting at secure :> level 3. : :You don't think that this discussion highlights the growing inadequacy :of the securelevel mechanism's lack of granularity? :Ciao, :Sheldon. It would be interesting to see it turn into a bitmask, where setting it to '-1' secures everything. But I think the original intent was to make it more user-friendly in concept. It is simply a matter of relative merit. If a high securelevel still allows most files to be modified, it might as well allow clearing of the ipfw counters. Ultimately the only way to do securelevel properly is with capabilities. The system gives init all the major capabilities and init passes them on as appropriate. A system-wide secure level for a feature is created simply by globally destroying a particular capability. It would also be possible to destroy all instances of a capability except in the specific processes that need it - though in that case you wouldn't be able to restart the process in question. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message