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

[Karp, Alan H]

Shap 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.

Do you mean authorities or permissions?  

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp
  
  

> -----Original Message-----
> From: cap-talk-bounces at mail.eros-os.org 
> [mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of Jed Donnelley
> Sent: Tuesday, October 09, 2007 9:53 AM
> To: General discussions concerning capability systems.
> Subject: Re: [cap-talk] Horton vs. ACLs - private namespaces 
> and the Audit Problem
> 
> 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/
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>