Greg Alexander wrote:
> Lemme see if I get the gist of what you're saying:
> Security shouldn't be implemented in the kernel.
> Security should be implemented in userspace daemons because then
> we could provide more complex security because people are more willing to
> put bad code in user space.
> Did I get that straight? :)
Straight, but not for the reasons stated.
The choices are not merely "kernel space" and "user space". There is (if
only logically) also "supervisor space" and "library space", both of
which can be considered "trustworthy".
The notion is that instead of attempting to put all of the rules into the
kernel, the kernel (work doer) would be separate from the authorization
mechanism (work allower).
I would see that this security model would be supported using dynamically
loaded modules, from a trusted location. Also, if an authorized agent
requested that a new version of the authorization tables be loaded, the
new rules could be invoked without taking down the system. (24x7x365.25
is important to my employer).
One should be able to provide auditors with the rules regarding access
that is independent of the requestors of the access. Further, the same
rules can be used for an enterprise wide solution, regardless of which
operating system is being used (if done right).
In the medical field (where my company works), it is necessary to have
very complex security. If this security can be managed independently of
the requestors, so much the better.
Sort of like not letting the architect build the building, or the
contractor design the building, much less the inspector being on the
payroll of either.
-- Cheers, --ldl ----------------------------------------------------------------------------- LD Landis ldl@HealthPartners.Com N0YRQ Voice 612/883-5511 Fax 612/883-6363 HealthPartners, 8100 34th Avenue So, PO Box 1309, Minneapolis, MN 55440-1309 Shape your life not from your memories, but from your hopes. (Borrowed) -----------------------------------------------------------------------------