[cap-talk] Horton vs. ACLs - private namespaces and the Audit Problem

[Jed Donnelley]

On 10/8/2007 9:18 PM, David Hopwood wrote:
> Jonathan S. Shapiro wrote:
>> The audit problem is to provide a mechanism by which an external
>> security auditor (a human using tools) can determine which programs have
>> access to which authorities.  There is an intrinsic conflict between the
>> desire for and utility of private namespaces and the desire for and the
>> importance of auditability.
> 
> Private namespaces are a non-negotiable requirement. The auditors will
> just have to deal with the fact that not all objects are referred to by
> human-friendly names -- which is true even in systems without private
> namespaces.

There's something else that I think I don't understand about
this "audit problem."  Namely, if we believe in fine grained
access control and small protection domains (e.g. at the level
of active objects in O-O programming) that are necessarily
very dynamic, what sense does it make for an auditor to
ask which programs have access to which authorities?  Certainly
in real time this would be an overwhelming amount of largely
meaninglessly transient data.  Even after the fact (e.g. in logs)
any execution environment that accessed an object may be so
fleeting that it seems to me that learning that this briefly
existing active object had some specific authority may not
mean too much.

I guess the idea is to back track to see where the authority
came from, e.g. to determine if some active object inappropriately
had some authority?

I know our main tool in this regard in our NLTSS work
(
http://en.wikipedia.org/wiki/NLTSS
)
was logging messages.  Since every authorization and every
exercise of an authority (e.g. what are typically referred
to as "system calls" on conventional systems) flowed over a
message, by logging all the messages we were able to see all
authorizations and any exercise of an authority.

I don't really see how one can do much better?  Is there
some reason such logs don't suffice for the "audit problem"?
Of course there is a certain amount of overhead with such
logging.  Because of that we generally didn't leave full
logging on all the time.  However, it wasn't so bad that
we couldn't.  Perhaps in modern systems that overhead wouldn't
be so bad or could be optimized sufficiently to be left on
all the time?  We had mechanisms to parse control messages
(where capabilities flowed) from such logs to make them
easier to read.  I well remember the delight of being
able to follow every detail of every interaction in a
message passing system such as NLTSS - a delight that I
miss in 'modern' systems where typically syslogged data
is at a much higher level.

I believe the value a facility like Horton achieves comes
from allowing people to manage access at a human meaningful
level - e.g. at the level of people or roles.  At that level
I do believe it does make sense to provide users information
about who has access to what, to be able to track delegation
trails and to be able to cut off access as needed.  This first
(being able to provide information about who has access to
what) and last (being able to cut off access) are values of
ACLs that Horton provides.  The delegation trail information
that Horton can provide goes beyond what is available in any
conventional system (e.g. ACL system) that I know of.

The information in the low level message logs like we had
in NLTSS (presumably other message passing systems have
similar logging facilities?) was really only meaningful
to system programmers.  Also it was only system programmers
that had the authority to access such logs - appropriately
I believe.  For us these logs were a bit like a systrace
in that every "system call" was a message.  Message logs
were deeper than typical syslog data on Unix systems.
Absolutely every action that crossed a domain (trust)
boundary (for us between processes, perhaps in even
finer grained systems between objects) could be viewed
in the message logs.

I'm not sure, but I think the above discussion is orthogonal
to what Jonathan and DavidH are discussing with regard to
"private namespaces".  However, perhaps the above could
provide some shared context in which they or others might
be able to further clarify the "private namespace" issue
so others of us can understand?

Is the "intrinsic conflict" that between what an auditor
might want to see (e.g. at the system programmer level) and
what an 'ordinary' user might be appropriately authorized to
view regarding logs?  I can't imagine what the issue is
with private namespaces if it goes beyond the above.  Even
access to something like open file descriptors in, say,
Unix, seems to me to go beyond any human meaningful
"name space".

Sorry if I'm missing something obvious.

--Jed  http://www.webstart.com/jed/