From owner-freebsd-arch Tue Oct 19 16:15:22 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id C11811807D for ; Tue, 19 Oct 1999 16:15:10 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id BAA16159 for ; Wed, 20 Oct 1999 01:15:05 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA87921 for freebsd-arch@freebsd.org; Wed, 20 Oct 1999 01:15:04 +0200 (MET DST) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id DC45B1808D for ; Tue, 19 Oct 1999 16:14:24 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40349>; Wed, 20 Oct 1999 09:09:51 +1000 Content-return: prohibited Date: Wed, 20 Oct 1999 09:14:13 +1000 From: Peter Jeremy Subject: Re: kern.securelevel and X In-reply-to: <19991019105525.A82390@bitbox.follo.net> To: freebsd-arch@freebsd.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Oct20.090951est.40349@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <19991017012750.A812@fever.semiotek.com> <380A1E2C.CCA326F5@gorean.org> <19991018024704.A512@semiotek.com> <19991018043039.B1711@semiotek.com> <19991018142633.D1DDB1DA3@bone.nectar.com> <99Oct19.142341est.40352@border.alcanet.com.au> <19991019105525.A82390@bitbox.follo.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Oct-19 18:55:25 +1000, Eivind Eklund wrote: >On Tue, Oct 19, 1999 at 02:27:48PM +1000, Peter Jeremy wrote: >[On using sysctl's for securelevel-style capabilities that can be > dropped] >> The disadvantage of this approach is kernel bloat: Each sysctl adds >> around 50 bytes of data overhead on an i386 (and about twice this on >> an Alpha). A single bitmap (which could still be a sysctl) of allowed >> syscalls would be substantially smaller and allow most of the permission >> checking inside trap.c:syscall(). Maybe I should have thought through this more completely... >First of all, I do not believe that the syscalls provide an adequate >mapping to which things you want to protect against. Agreed - in most cases, a high `securelevel' requires restricting the functionality of a syscall, rather than totally blocking the syscall. >Second, looking at the syscall list, I find the following syscalls you >might want to block I hadn't worked through this. If it's only 20-30 system calls, then the sysctl approach is probably reasonable. I was concerned that we might be talking about adding this to the majority of syscalls. > (and which are not already handled by securelevel >(with better semantics)): I thought that one of the ideas here was to dump the existing securelevel and replace it with a more fine-grained approach (similar to capabilities). >If the kernel bloat is seen as a problem, In this case, it's probably not a problem. IMHO, we should consider the bloat factor when looking at new features - we're not trying to emulate Windoze2000. Peter -- Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message