[cap-talk] Horton context presentation (was Re: What does the [defense?] security community really fear from capabilities?)
David Chizmadia (JHU)
chiz at cs.jhu.edu
Fri Jul 13 21:40:20 EDT 2007
Hi all,
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, while presenting
object capabilities - and specifically the Horton protocol - as a
valid alternative for academic and industrial research and development.
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. The "in-the-box" response 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. 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.
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).
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.
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.
I hope that Jed and MarkM find this to be a useful contribution
to the discussion...
-DMC
Jed Donnelley wrote:
> Jonathan S. Shapiro wrote:
>> On Thu, 2007-07-12 at 11:18 -0700, Jed Donnelley wrote:
>>
>>> Jonathan S. Shapiro wrote:
>>>> On Thu, 2007-07-12 at 16:20 +0200, Pierre THIERRY wrote:
>>>>
>>>>> Scribit Jed Donnelley dies 11/07/2007 hora 16:52:
>>>>>
>>>>>> However, at the time vendors were working hard on supporting MLS
>>>>>> policies and it was widely believed that support for such facilities
>>>>>> would be available in those commercially available systems
>>>>>>
>>>>> If I understand correctly, to summarize, caps were disregarded because
>>>>> they had been considered unable to support MLS policies in favour
>>>>> of ACL
>>>>> systems, which at that time did not support MLS policies yet.
>>>>>
>>>> Not quite. Caps were disregarded because it was believed that they were
>>>> unable **in principle** to support MLS.
>>>>
>>> The above is a considerable over simplification.
>>>
>>
>> I agree. I was trying to respond in context to Pierre's specific
>> question.
>>
>> While I agree with much of Jed's diatribe on this topic -
> Note that I'm experimenting with approaches (some more salacious than
> others - e.g. specifically
> targeting the Microsoft first law) to get feedback from this list about
> what might work best
> for the "setting the context" intro for the Horton presentation prior to
> the workshop discussion
> at HotSec 07, taking place 8/7. I see this as an important opportunity,
> so regarding:
>> we seem to
>> have hit a widely shared tender nerve here -- I suggest that it isn't
>> productive to fight a 30 year old political battle. Most of the
>> opposition is dead or retired, and the only reason that people today
>> will know about that report is that Jed scanned it and put it online.:-)
>>
> I only dug up that paper because Bill Tulloh brought it to my
> attention. He was,
> as he said in:
>
> http://www.eros-os.org/pipermail/cap-talk/2006-October/005796.html
>
> "I've been trying to trace the history of capability-based approaches
> in the context of the emergence of the Trusted Computer Systems
> Evaluation Criteria (the Orange Book). Whether or not
> capability-approaches in general and GNOSIS/KeyKOS in particular fit
> with the approach of TCSEC was a question that was asked repeatedly
> during the 1980s. Although not necessarily classified, a lot of the
> documents from this period are not easily accessible, so what I've
> been able to piece together so far is rather spotty. I was hoping that
> people on this list (especially the KeyKOS folk) might be able to fill
> in some of the detail."
>
> That pursuit led him to:
>
> Gligor, V., Huskamp, J., Welke, S., Linn, C., and Mayfield, W.,
> ``Traditional Capability-Based Systems: An Analysis of Their Ability to
> Meet
> the Trusted Computer Security Evaluation Criteria,'' IDA Paper Pl 935,
> February 1987.
>
> In response to his request I asked a colleague who was one of the
> authors of that document, Jeff Huskamp, if he could send me a copy.
> He did and that's what I read and scanned into:
>
> http://www.webstart.com/jed/papers/P-1935/
>
> One minor point - I think some of the times and dates need to be corrected
> in Jonathan's message. That 'political' battle is 20 years old
> (1987-2007),
> not 30 years old. I'm not sure how to interpret the date in this sentence:
>
>> In 1974, when this report was funded, KeyKOS was only just getting
>> first funding.
>
> I can only guess that he means 1984 rather than 1974? Beyond that, let me
> respond to the substance of Jonathan's notes and try to tie them into how
> to approach the HotSec presentation and generally the effort to get closer
> to POLA - as I hope by legitimizing object/capabilities.
>
>> To the extent that there are factual issues (statements that are wrong)
>> or bad science (FUD) in that document, it is worth organizing a rebuttal
>> document. At this point, I think that cause and motives are largely a
>> dead issue.
>>
> While it may be that the detailed "cause and motives" are a dead issue,
> I believe
> that documents of that sort (there are others - e.g. that reference it,
> it was just
> the most focused, e.g.:
>
> http://www.fas.org/irp/nsa/rainbow/tg003.htm
> also at:
> http://www.iwar.org.uk/comsec/resources/standards/rainbow/NCSC-TG-003.html
> and others...
>
> ) that reflect the same thinking still represent the dominant thinking
> in the computer security community.
>
> Just consider this from the above document:
> ___________________
> A pure capability system includes the ability for users to pass the
> capability
> to other users. Because this ability is not controlled and capabilities
> can
> be stored, determining all the users who have access for a particular
> object
> generally is not possible. This makes a complete DAC implementation,
> including revocation, very difficult.
> __________________
>
> (by ", very difficult" I think they mean impossible) and later:
> __________________
> Capabilities could be useful in enforcing the least privilege principle and
> providing dynamically changeable domains, making discretionary access
> controls
> less vulnerable to Trojan horse attacks. However, in order to pass the
> class
> C2 and above DAC requirements, the ability for users to pass
> capabilities to
> other users must be sufficiently controlled. There could be some design
> difficulties in building capability-based mechanisms to satisfy the B3 DAC
> requirement because of difficulty in implementing precisely defined groups
> [11]. Also, at class B3 it is required that users be able to specify a
> list
> of users that have permission (or do not have permission) to access each
> object. Capability-based systems are row-based mechanisms and do not
> easily
> lend themselves to this function. Deletion of an object from the system
> and
> revocation of access present yet another problem. The problem is that
> row-based systems do not provide an efficient means of determining which
> users
> have access to a given object.
> __________________
>
> These views were by far the dominant view in the computer security
> community of the time. In my view, when the computer industry rapidly
> expanded in response to practical home computers and the Internet (starting
> at about that time, 1987 and continuing through the 1990s) these views were
> essentially frozen into place as orthodoxy. An orthodoxy that persists to
> this day.
>
> I can't tell you how many times I've brought up POLA (which seems to
> me a bit difficult to argue against) and object/capabilities as a
> technology
> for dynamic management of permissions that can support POLA, only
> to have people react along the lines of:
>
> "Oh, sorry poor sot. Didn't you get the news? Capabilities were
> discredited in the late 1980s. Didn't you hear that they can't
> effectively do mandatory or discretionary access controls and
> that even if they could they are overly complex and can't be
> implemented efficiently?"
>
> I believe this is the view that is still ascendant. Isn't it? If not
> then I should indeed refocus the Horton HotSec context presentation.
>
> I spent much of yesterday in a moderately interesting Web presentation
> by a guy who uses Redhat systems (with their SELinux support) for
> government systems support. His language was very much like
> that in the TCSEC/Rainbow papers. Of course he's probably never
> heard of capabilities, but I believe that if pressed he would go back
> to papers like the above to support his dominant view.
>
> If this isn't the view still held then this would be a good time to get
> documentation for whatever view is currently dominant so that we
> can fit the Horton presentation into the correct context.
>
> I spoke with MarkM yesterday afternoon. He indicated that
> the view at Google is much more positively disposed toward
> object/capabilities. If so, then perhaps there is more hope than
> I imagine. Still, I believe the prevailing computer security
> "mafia" (DOD, etc.) will not allow object/capabilities to
> even creep back into the lexicon, let alone see any large
> scale commercial use without fighting back with these arguments
> that I believe still represent their views.
>
> If I'm way off in this view, then I need to get some pointers
> to documents that can be used to support a new rise in
> support for and use of object/capabilities for POLA. It
> would be a much more positive message at HotSec to
> suggest that a new rise in the use of object/capabilities in
> support of POLA is well underway and that Horton just
> adds fuel to this fire by showing how identities and
> responsibility tracking can be included in this newly
> fashionable object/capability paradigm.
>> I did once have occasion to talk to Virgil Gligor about some of this
>> stuff (though not about the report specifically). Part of what we all
>> need to remember is that these authors were charged with a very serious
>> and very real problem. They had to come up with a recommendation in an
>> environment where capability ideas were not widely circulated.
> Indeed.
>> In 1974, <as I mentioned above, this must mean 1984?? >
>> when this report was funded, KeyKOS was only just getting first
>> funding.
>>
> While this was true in 1984, capability based systems had been around
> for quite some
> time at this point. Ah, here is a summary to 1982 from Bill Tulloh:
>
> http://www.nabble.com/On-the-Spread-of-the-Capability-Approach-t2037962.html
>
>
> 1966: Dennis & Van Horn paper - MIT
> 1967: PDP-1 Supervisor - MIT
> 1967: Magic Number Machine - University of Chicago
> 1968: CAL-TSS - Berkeley
> 1969: System 250 - Plessey Corporation
> 1970: CAP - Cambridge University
> 1971: Project SUE - University of Toronto
> 1971: Hydra - Carnegie Mellon
> 1972: RATS - Lawrence Livermore
> 1973: Actors - MIT
> 1973: PSOS - SRI
> 1975: StarOS - Carnegie Mellon
> 1975: GNOSIS/KeyKOS - Tymshare
> 1976: Monads - Monash University
> 1978: System/38 - IBM
> 1978: NLTSS - Lawrence Livermore
> 1980: SWARD - IBM
> 1980: PDP 11 operating system - University of Texas
> 1981: Amoeba - Free University Amsterdam
> 1982: iAPX 432 - Intel
> 1982: Password-Capability System - Monash University
>
> The Levy overview of Capability systems was written in 1984:
>
> Levy, Henry M., /Capability-Based Computer Systems/, Digital Equipment
> Corporation 1984. ISBN 0-932376-22-3
> <http://en.wikipedia.org/w/index.php?title=Special:Booksources&isbn=0932376223>.
>
>
> http://www.cs.washington.edu/homes/levy/capabook/
>
> That book seemed pretty even handed to me.
> <http://www.cs.washington.edu/homes/levy/capabook/>
>> Outside of Cambridge, UK, which was never a group that published much,
>> the ideas we now take for granted in cap systems
> I certainly was never significantly influenced by the cap systems.
>> were not known to the community at large (and still aren't).
>>
>> It would have been much better for that report to have said "We see the
>> following issues, we are not aware that solutions exist for them." But
>> try to remember that the authors were very young in their careers. The
>> ability to admit lack of knowledge is a hard thing for anyone, harder
>> for early-stage scientists, and the stakes involved were really high.
>>
>
> They absolutely slammed capabilities. Their intent was to show that
> capability
> systems could not be used to effectively secure computer systems. They
> succeeded in stopping any such development and turned the focus of
> efforts almost completely to user/ACL based systems in support of MAC, etc.
> To be sure they were speaking to a community already quite prepared to
> accept that the dominant user/ACL mechanisms already seen in the most
> significant commercial systems such as Unix and VMS was the right way
> to go. This TCSEC, Orange Book, etc. work really just cemented this
> paradigm into place and effective froze out any alternative - for many
> years to come.
>
> The stakes were high and the result was huge. There were no serious
> efforts
> at capability based computing that I know for many years after that period.
> KeyKOS struggled along a while, trying to paddle against a very strong
> current and then had to give up. No other significant efforts were
> launched.
> All previous work gradually faded into insignificance.
>
> It is clear why this was (has been) the case. The prevailing mind set
> (attitude, belief, thought, etc.) in the computer security community
> is still that object/capabilities never were and never could be made
> practical. While POLA by itself is a nice principle, it too is impractical
> (e.g. Lampson's comments - not difficult to see if you try to do
> POLA with ACLs) to be used in practice.
>
> I believe that to this day this is the prevailing mind set that we need
> to counter from this "cap-talk" community if we are ever going to get
> any traction in using object/capabilities in support of POLA.
>
> Thanks for any time to review, correct, clean up, etc. the views
> expressed above. MarkM will be the one to make a final
> decision about what to discuss as a prelude to the Horton
> HotSec presentation, but I'm working on thoughts along the
> above lines for those first few charts and few minutes of
> an introduction to the context of the problem that Horton
> is solving.
>
> --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
More information about the cap-talk
mailing list