Proposed changes to suser()

[Spencer Minear]

I would suggest that there is value in viewing the use of the likes of
cap_check_xxx, or suser_used as an example of a clean simple entry
into the the system "security policy logic".

If you take that view and open up that interface to be a bit more
general, you might find that the calling code gets even cleaner.  You
will find that it is no longer necessary to have the audit generation
logic spread all over the kernel.  Rather it can become part of the
security policy decision logic and the generation of audit then
becomes just an aspect of the system security policy that can be
easily tuned to specific sites and installations as appropriate.  It
should not be a hard-coded decision on the part of the kernel
developer.

You will end up with a cleaner system where the kernel processing
logic focuses on operational processing with well defined check points
that act as simple policy controlled gates.  It also leads to an
implementation where the security policy logic, including audit
generation code, is embodied into the security decision logic that is
much easier to find, make consistent in behavior across the system,
maintain, analyze and all those other things so important when dealing
with system security.

For example, one piece of information that missing if you just provide
support for the IEEE capability model is the identity of the target of
the operation.  Leave this off and and you will have support for only
a one dimensional privilege mode based on the actors identity.  Yes
many of the checks in the system are inherently a one dimensional in
nearly every secure OS implementation I've worked on or read about.
BUT there are a non trivial number of the checks were having the
identity of the target of the operation, not just the identity of the
initiator of the operation, will allow support for a much stronger
form of security at no extra cost.  If you are going to change the
suser interface model, now is the time to look at how to make it just
a bit more general over the requirements to support the IEEE
capability model and you will find that a range of better security
options can be had for a very little extra work.

-- Spence Minear
To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message