Date: Thu, 08 Jun 2000 03:25:13 +0900 From: "Daniel C. Sobral" <dcs@newsguy.com> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: Matthew Dillon <dillon@apollo.backplane.com>, Bjoern Fischer <bfischer@Techfak.Uni-Bielefeld.DE>, hackers@FreeBSD.ORG Subject: Re: kerneld for FreeBSD Message-ID: <393E9389.EB7C0F3F@newsguy.com> References: <Pine.NEB.3.96L.1000607075658.25263A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote: > > I tend to agree, on face value, with an intuitive objection to kerneld. > That said, it should be observed that a "kerneld" would restrict the code > sufficiently privileged to cause a module load in one binary, as opposed > to a model where that type of privilege has to be provided to hundreds of > them (even huge beasts like ppp). If requests for kernel functionality > loads come through a well-audited (both senses) and well-defined LPC > mechanism, there is substantially less risk involved. In a world where > dynamic kernel module loading occurs even after entering secure, > multi-level operation, that type of protection seems like a good idea. It > would allow us to distinguish the following privileges: > > 1 Right to request specific functionality be loaded > 2 Right to load the functionality > 3 Right to invoke the functionality > > Letting, say, ppp have (1) and (3) but not (2) provides a substantial > security improvement, while retaining the ability to introduce new > functionality at run-time. Wow, for the first time someone makes a *GOOD* case for kerneld! -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@yet.another.bsdconspiracy.org Hmmm - I have to go check this. My reality assumptions are shattered. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?393E9389.EB7C0F3F>