[cap-talk] Google TechTalk lecture series, HP

[Karp, Alan H]

> -----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, July 11, 2006 4:52 PM
> To: General discussions concerning capability systems.
> Subject: Re: [cap-talk] Google TechTalk lecture series, HP
> 
> At 06:27 PM 7/8/2006, Nigel Williams wrote:
> 
> 
> 	Found this, firstly featuring Alan Karp:
> 	 
> 	http://video.google.com/videoplay?docid=-7179100659758053865
> 	 
> 	over the next three weeks Mark Miller, Tyler Close, and 
> Mark Stiegler.
> 	 
> 	cheers,
> 	nigel.
> 
> 
> Interesting.  Why is it that we didn't hear about these presentations
> from the speakers (Alan?)?

Because I didn't know it had been posted yet.  I just figured that
Google was as efficient as HP :)
> 
> If folks don't mind I'll make some comments on the talks as I
> view them.  First on Alan's.  Of course let me preface this
> by stating what I hope it's obvious that I'm quite supportive
> of this basic POLA approach and generally the sorts of
> mechanisms that Alan and the others at HP are using.
> 
> 1.  05:40: "This approach <POLA> has been used many
> times in the past and it has always failed."

I don't believe that I said that POLA failed.  At least I didn't intend
to.  What has failed are systems that enforce fine-grained access
control and continually ask for confirmation, e.g., Java WebStart.  Your
point that combining designation with authorization "has simply been
essentially ignored" is exactly the point I was trying to make.
> 
			(snip)
> 
> Please (!) don't bundle all the historical capability efforts
> into "always failed" along with the ACL models.  I never
> got a popup dialog in any of the capability systems that
> I worked on.   There were no such out of band security
> decisions, etc.  Designation and authorization were always
> combined (just like with "webkey"s, exactly like "webkeys"),
> so please don't suggest that they weren't and that combining
> designation and authorization are a new discovery.

At this point, I'm not talking about capabilities.  I'm talking about
fine-grained access control in systems most people are familiar with.
The example is purposely fuzzy.  After all, when I double-click on the
icon for a spreadsheet, am I asking to edit the file or just read it?  A
true capability system allows me to make that distinction.  What I
described at this point in the talk doesn't.
> 
> You can argue if you like that the combining of designation
> and authorization in GUIs is novel to Mark Miller and the work
> at HP.  I won't dispute that, but please (!) don't distance yourself
> from the history of capability system developments ("it always
> failed").

Again, I've made no mention of capabilities.  We've known that
capabilities combine designation with permission since DVH.  That is,
the capability itself is both the desgination and the permission to
invoke.  That's not what Stiegler's insight is all about.  He recognized
that something in the system can infer what authorizations to grant
based on the user's act of designation.  It is this inference that was
missed in earlier systems, and that's what led to denial of service by
dialog box.  The inference is implicit in capability systems, but not on
other systems.
> 
> "Web keys": combining Web services with no glue code?
> No mention that these "web keys" are exactly what is
> needed to combine designation with authorization
> ON THE WEB! <Internet>??!

I do make that point when discussing the slides.  By the way, I hope I
said "with little or no glue code".
> 
> Sad Tale of Zebra Copy and ABAC.  Good example, and I
> think it helps get the base point across.  A couple of comments.
> 
> You say that revocation is easy, but there's no suggestion
> as to why revocation is easier with ABAC vs. IBAC.  I believe
> you should mention that the bundles (designation and authorization)
> can be easily (simple record keeping, like creating a new file)
> reissued with different authorization (e.g. less authority,
> or a note about Carol's use vs. Bob's use).  That is, Bob can
> give Carol a new authority, derived from one of Bob's fine
> authorities, that is just for her use.  It's that Carol authority
> derived from Bob's that can be revoked - by Bob.

There are many such points that need discussing.  Indeed, I gave a 50
minute keynote at a recent e-commerce conference where I made many of
them.  Unfortunately, there just isn't time in the few minutes I can
devote to the subject in an overview such as this.
> 
> I think we see the same picture here (if not, please let
> me know), but in the presentation your claim (that revocation
> is easy with ABAC) sounds vacuous.

Again, the details matter.  In practice, most people think of these
authorizations as digital certificates that can be put onto a CRL.
That's the example I use when the issue is raised during the questions.
It's good enough to make the point.  Of course, capabilities are far
better, but I don't have to get into that during this talk.
> 
> Excel example  under Polaris (41:37 - needless to say
> those failures are very bad news for the reputation of Polaris).
> Suggests that these (POLA) are good principles, but
> impractical.  The virus decided to die?  It appears that it's
> Polaris that decided to die.  Is the virus something you
> wrote?  Too bad that happened in this situation.

As I think I said in the talk, "The virus has a bug and failed.  That's
a good thing."  In fact, the virus is a simple VBScript that Stiegler
wrote.  We have no idea why the error occurs where it does.  The script
isn't even being invoked yet.  To make matters worse, the error is
intermittent.  It ran just fine after the cameras were shut off.
> 
> The comment about "acts of designation available to
> the user but not to the virus" I like.

Thanks.  Nobody has asked how that happnes.  It's a tricky point that
even Microsoft appears not to understand.
> 
> Regarding the "We do the best we can with Polaris"
> and the attack of trying to get a user to run outside
> Polaris.  I think that would be a good time to tie back
> to the Solitaire program and how it can run with only
> the authority it needs.

I don't understand.  If a virus can make polarized Solitaire look like
it's acting funny, a user might open it with full privilege.
> 
> Note on the Polaris name (at the end) - like it.  I hadn't
> heard that before.

As usual, it took several hours to come up with the acronym once we had
the name.
> 
> Very end - "mutable static state"?  Did you mean "mutable
> global state"?  "mutable static" sounds like an oxymoron.

"Static" is a Java term.  I should indeed use the word "global".
> 
> That talk was on the 5th?  My birthday.  I hope you had as
> much fun that day as I did Alan... 
> 
Happy Birthday to you!!!  How does it feel to be an old man of 40?

I did indeed have fun (would have had more fun had the virus run :).

________________________
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
  
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Karp, Alan H.vcf
Type: text/x-vcard
Size: 433 bytes
Desc: Karp, Alan H.vcf
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20060711/14277dc7/attachment.vcf