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)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Hmmm - I have to go check this. My reality assumptions are shattered.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message