[cap-talk] Horton context presentation (Chizmadia)

[David Chizmadia (JHU)]

Jed,

    Some of my initial reactions...

Jed Donnelley wrote:
> At 06:40 PM 7/13/2007, David Chizmadia (JHU) wrote:
>> Hi all,
> 
>>     I hope that Jed and MarkM find this to be a useful contribution
>> to the discussion...
> 
> All contributions are very welcome, especially one so carefully
> thought out.
> 
> At this point MarkM is quite busy - hopefully move available soon.
> I've adopted the role of gathering input and vetting ideas for
> laying the context of Horton for the HotSec discussion.
> 
> I seem to be best able to interpret/respond to your suggestions
> back to front David.  I hope that works OK for you.  Regarding:
> 
>>     The Horton protocol is motivated by the Object Capabilities
>> community's efforts to provide fine-grained accountability of the
>> actions of agents - generally under the direct control of human
>> users - in an system built using object capabilities.
> 
> While it is true that Horton provides this value, so I guess
> you can say Horton "is" motivated by a desire to provide for
> accountability of agents with ocaps, in fact the initial
> motivation for Horton was to respond to the criticism in
> P1-935: http://www.webstart.com/jed/papers/P-1935/
> that "traditional" capability systems (by that they
> meant object/capability systems) could not provide
> accountability (log, audit, control by identity) for
> actions enabled by permissions.  I read that criticism
> and said to myself, "Wait a minute.  It's true that I've
> never seen such a mechanism in an object/capability
> system, but it seems to me that it can be done."  I
> pushed on it a bit on this list and MarkM responded
> with a draft (discussed in detail 12/1/06 at HP:
> 
> http://www.webstart.com/projects/delegating-responsibility/HP-2006-12-01/
> e.g.: 
> http://www.webstart.com/projects/delegating-responsibility/HP-2006-12-01/markm-jed-dr-draft.jpg
> 
> ) and later a full implementation.
> 
> That is how I remember the motivation and development.
> 
> Perhaps what you are suggesting is that for a presentation on the
> context of Horton, the actual motivation and development isn't
> worth mentioning, but rather the emphasis should be placed on
> the value that Horton can supply in the context of an
> object/capability communication system?

    The issues raised by the IDA paper are the ones that I stated.
Perhaps the best way to approach this is to add an additional
sentence along the lines of:

        "These efforts are in turn motivated by the criticism of
        raised in (the IDA paper) that capability systems cannot
        provide accountability for use of individual capabilities."

> 
>>     I'd like to suggest a slightly different approach to introducing
>> the motivation for Horton. It acknowledges the current dominance of
>> the ACL/Label-based approach to access control,
> 
> By naming Microsoft's first immutable computer security law:
> 
> Law #1: If a bad guy can persuade you to run his program on
> your computer, it's not your computer anymore.
> 
> It seems to me that in quite a tight package (text) we both
> acknowledge the overwhelming dominance of the user/ACL
> paradigm for access control and at the same time clearly
> point out what a serious problem this dominance causes.
> 
> Do you disagree?  I'm very partial still at this point to
> using Law #1 to focus attention on the problem with the
> dominant user/ACL access control paradigm.  Do you (others)
> disagree?  If so, can you explain why?

    I would see Law #1 as a rather good summary of the problems with
existing models. It then provides an opening for an aside that the
ocap community is convinced that ocaps provide an opportunity to
disprove the law.

>> while presenting object capabilities - and specifically the
>> Horton protocol - as a valid alternative for academic and
>> industrial research and development.

    Valid was never the word I wanted. I meant something more along
the lines of "...as a promising alternative approach to mitigating
the known problems while providing the same set of functions."

> Of course object/capabilities have been a 'valid' alternative
> for the academic and R&D community for some 40 years.  This
> seems to me not a very novel announcement.  They essentially
> disappeared off the map from the late 1980s until recently.
> 
> Arguing that they are newly valid (again valid, now have
> more validity, etc.) does seem to me something new.  As I
> mentioned, I am encouraged by the capability note in Alan
> Kay's research proposal:
>
> "...The capability approach to modern protection via message
> sending which give rise to promises for future transactions
> is very compatible with our work..."
> 
> that might be considered suggestive enough of a renaissance
> in the use of object/capabilities at least again in the R&D
> environment to motivate work on incorporating delegation
> of responsibility by identity in such an environment?
> 
> Again that isn't how Horton came up, but perhaps we can
> (should?) point to this as a 'motivation' for the Horton
> work/protocol?
> 
> I'm throwing out ideas that seem to be along the lines David
> is suggesting.  I still feel that accurately describing
> what the motivation was for Horton as it arose on cap-talk
> after the review of P1-935 is the more appropriate/effective
> approach.  I believe there is a very large community interested
> in computer security for which the criticisms of P1-935
> (Rainbow, Orange Book, etc., etc.) still ring very true.
> People who can't really imagine object/capabilities with
> any notion of identity/responsibility.  For them I think
> Horton will be a surprise that might suggest that perhaps the
> object/capability paradigm has more legs than they imagined.

    I should note that I still identify closely with that TCSEC
community - since I was a member of it from 1986-1996. I worked
closely with many of the people who wrote the IDA document - either
as a contract manager or a colleague on specific evaluation or
guideline projects. On the other hand, since 1996 I've been working
with the OMG and therefore have developed a strong affinity for the
O-O approach to thinking about designs.

    The interesting thing is that I haven't seen any conceptual
problems with using ocaps as the basis for other models. I simply
view all other models as a matter of creating very precisely
constrained and enforced introduction models. In fact, one of my
current daydreams is to go back for a PhD, where my thesis would be
demonstrating that any enforceable access control model can be
contructed on top of a primitive ocap model.

    The bottom line is that for many of these people, success speaks
more loudly than theory. That's why I wanted to nudge the Horton
talk in the direction of presenting the ocap efforts as a parallel
approach and Horton as a step towards creating a more complete
theoretical and operational foundation.

> 
> I believe they will continue to be quite uncomfortable
> with permissions being communicated across any available
> communication path (collaborating conspirators - enabled
> without proxying by default ocap semantics).  I feel it's
> important to include this issue in setting the context
> for Horton.  You (others) not?  They may not see in the
> paper how P2 could be sent directly to B if A had the
> ability to communicate directly to B, but I think it is
> important to be up front about this.  If not and it's brought
> up, we could end up looking like we got caught with our
> pants down.  Others?
> 
>>     The core of the argument is to note that the limitations of
>> ACL/Label-based access control in controlling semi-autonomous
>> applications of potentially dubious provenance and pedigree have
>> been well-known in the "traditional" computer security community
>> since the late '80's.
> 
> and before I would argue.  The Trojan horse problem was well
> know at least when I started working on it in 1973 or so,
> likely much before.  However, it's only been during the era
> of widespread distribution of software (home computers and
> the Internet) that this problem has really begun to bite.

    I look at things from my perspective... ;-)

    I was aware of papers and research in the late '80's - I have no
doubt that many of the issues were known earlier.

> 
>> The "in-the-box" response
> 
> Can you explain what you mean by "in-the-box"?

    Approaches that derived from the well-known and -understood
model of attaching ACI (access control information) to target
objects and then forcing access requests to go through a gatekeeper
that checked the ACI of the target against the ACI of the initiator.

> 
>> was the research
>> that led to Secure Computing's Type Enforcement (which is the
>> technology model of SELinux) and TIS's Domain and Type Enforcement.
>> A case can probably be made that systrace is in the same category.
>> The problem with these approaches is that they require explicit
>> specification of AC policy in order to operate, which imposes a
>> substantial training and time burden on system administrators.
> 
> We agree.  I believe this is where much of the complexity
> and admin. burden for POLA in general comes from that finds
> it's way (incorrectly in my opinion) into a criticism
> of object/capabilities.
> 
>> As a
>> result, the adoption of these technologies continues to be very
>> slow: thus leaving most existing systems open to the known design
>> vulnerabilities of ACL/Label-based access control.
> 
> We agree.  This is what you feel we should emphasize in the
> limited time we have to lay the context for Horton at HotSec?
> 
> <out of context:  One thing that I was recently very struck
> by was the DEFINITION of discretionary access control, DAC,
> as being control by the "owner" of an object - e.g. in the
> Rainbow paper.  This definition seems to me fundamentally
> at odds with object/capabilities and essentially with
> the communicating conspirators problem>
> 
>>     In addition, many applications are now developed using
>> object-oriented principles, techniques, and languages. In large
>> part, this is due to the intrinsically objected-oriented nature of
>> HTTP and the resulting affinity of web programmers for O-O languages
>> (e.g., Java, PHP, JavaScript, Ruby, and Python).
> 
> I agree that this is important to mention.
> 
>>     An active community of people coming from the traditional
>> capability computing tradition have noted that capabilities also
>> have a natural affinity for the O-O model (cite the papers by Shap,
>> Ka-Ping, Alan, MarcS, and MarkM). This community is experimenting
>> with "Object Capabilities" as a promising alternative to
>> ACL/Label-based access control. An important aspect of the Object
>> Capabilities research and experimentation is finding ways to
>> effectively and efficiently provide all of the features that
>> ACL/Label-based access control systems are claimed to exhibit.
> 
> Ah, and one of those features is log/audit/responsibility
> tracking?  Hence Horton?  That would then tie back to the
> criticisms of ocaps as per P1-935 and Rainbow, Orange Book,
> etc.?
> 
> I see the above as having a lot in common with what I've
> been throwing out in admittedly a rather a loose/unstructured
> way.  Perhaps you could suggest where you see the primary
> differences are that we should focus on?
> 
> Thanks again for taking time to write David!  I hope we can
> come to some sort of cap-talk consensus on the appropriate
> introduction/context for Horton.  The final choice with
> be MarkM's.
> 
> --Jed  http://www.webstart.com/jed-signature.html 
> 
> 
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
> 
>