Date: Wed, 20 Oct 1999 09:14:13 +1000 From: Peter Jeremy <jeremyp@gsmx07.alcatel.com.au> To: freebsd-arch@freebsd.org Subject: Re: kern.securelevel and X Message-ID: <99Oct20.090951est.40349@border.alcanet.com.au> In-Reply-To: <19991019105525.A82390@bitbox.follo.net> References: <19991017012750.A812@fever.semiotek.com> <380A1E2C.CCA326F5@gorean.org> <19991018024704.A512@semiotek.com> <xzpyad12jd7.fsf@flood.ping.uio.no> <19991018043039.B1711@semiotek.com> <xzpso392gj0.fsf@flood.ping.uio.no> <19991018142633.D1DDB1DA3@bone.nectar.com> <xzp90503esj.fsf@flood.ping.uio.no> <99Oct19.142341est.40352@border.alcanet.com.au> <19991019105525.A82390@bitbox.follo.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99Oct20.090951est.40349>