headers
Norman Hardy | 2 May 2008 19:19

Re: [tahoe-dev] Sharing Tahoe file system directories? Loops, lost objects, etc.


On 2008 Apr 15, at 14:08 , Jed Donnelley wrote:

> Why would I want a shallow read-only directory capability?  One  
> example
> is to manage a project with other colleagues who I trust with write
> access to some of the underlying objects.  I can manage the project by
> choosing what to put into the shallow read-only directory (including
> whether some of the pieces are writable, shallow read-only, or deep
> read-only capabilities to directories) - nobody who I give it to can
> modify it - but everybody who I give the shallow read-only capability
> to can extract what's in it and write to that which I choose to share
> write access.

Keykos provides a RO key to a node (cap page).
It was seldom used but there was at least one important use.
Each yield of a particular factory would have a RO key to the node of  
holes for that factory.
(See http://cap-lore.com/CapTheory/KK/Factory.html for factories and  
holes.)
Had the yields had a write key to the node they would not have  
isolated from each other.
A hole is a key found in that node which has been vetted to be trusted  
to be held and shared among yields of this factory.
Permalink | Reply | 1 comment |
headers
Jed Donnelley | 3 May 2008 12:24

Re: [tahoe-dev] Sharing Tahoe file system directories?

At 10:19 AM 5/2/2008, Norman Hardy wrote:
>On 2008 Apr 15, at 14:08 , Jed Donnelley wrote:
>
> > Why would I want a shallow read-only directory capability?  One
> > example
> > is to manage a project with other colleagues who I trust with write
> > access to some of the underlying objects.  I can manage the project by
> > choosing what to put into the shallow read-only directory (including
> > whether some of the pieces are writable, shallow read-only, or deep
> > read-only capabilities to directories) - nobody who I give it to can
> > modify it - but everybody who I give the shallow read-only capability
> > to can extract what's in it and write to that which I choose to share
> > write access.
>
>Keykos provides a RO key to a node (cap page).
>It was seldom used but there was at least one important use.
>Each yield of a particular factory would have a RO key to the node of
>holes for that factory.
>(See http://cap-lore.com/CapTheory/KK/Factory.html for factories and
>holes.)
>Had the yields had a write key to the node they would not have
>isolated from each other.
>A hole is a key found in that node which has been vetted to be trusted
>to be held and shared among yields of this factory.

I don't think I follow your reasoning/example above Norm.

I was trying to suggest to tahoe-dev that there is value in
"shallow" RO (what one usually refers to as simply RO) for
directories that make it helpful even if one has deep RO.  In
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ivan Krstić | 4 May 2008 04:29
Picon
Favicon

Security and languages talk

I'm directing much of my recently-gained spare time[0] towards a few  
things I've wanted to work on for a while, but haven't had the time in  
the course of my breakneck two years with OLPC. One such thing is,  
after giving a bunch of high-profile talks about systems security,  
writing a short one about security and programming languages.

The Boston Lisp folks invited me to give the talk[1] on May 27th, so  
the audience is a fairly clueful programming crowd without any  
necessary prior exposure to language security and capability ideas.  
I'll be talking for 25 minutes: covering the basic ideas and looking  
briefly at things like E, Joe-E, Caja and CaPerl.

Questions for this crowd:

* Have you seen any _great_ short introductory capability and
   language security talks before? What made them great?

* What do you think are things that I absolutely must cover?

* If this was your first brush with the relevant topics, what could
   I say that would really pique your interest?

Cheers,

[0] <http://radian.org/notebook/maintaining-clarity>
[1] <http://radian.org/notebook/talk-language-security>

--
Ivan Krstić <krstic <at> solarsail.hcs.harvard.edu> | http://radian.org
(Continue reading)

Permalink | Reply | 27 comments |
headers
Baldur Johannsson | 4 May 2008 05:37
Picon

Re: Security and languages talk

Two urls turn up from my bookmarks that could fit your criteria:

http://www.skyhunter.com/marcs/capabilityIntro/index.html
http://www.eros-os.org/essays/capintro.html

the latter one I found rather concise and illuminating when I first read it.
What piqued my intrest was I felt that static policies were too
acidential complexe. That and the need for easy delegation
 (I seen this first hand) leads cooperating people to share passwords
and/or complete
access to everything.

But I guess that "the Mashup proplem"* might be more intresting to more people.

What you must absolutly cover is than an capability is an unforgable**
reference/token
 that both designates the object and the authority to use that object.
 That an capability doesnt care who uses it and (this often asked) how
an capability can be rescinded using the forwarder pattern.

I am sure other cap-talk list members have more to add.

Thoughts? Comments? Need for clarification?
-Baldur Jóhannsson

* http://www.youtube.com/watch?v=V13wmj88Zx8 found at
http://wiki.erights.org/wiki/Documentation

** in OS or language based system that is usually forbids that an
program fabricating
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jed Donnelley | 4 May 2008 09:21

Re: Security and languages talk

At 07:29 PM 5/3/2008, Ivan Krstić wrote:
>I'm directing much of my recently-gained spare 
>time[0] towards a few  things I've wanted to 
>work on for a while, but haven't had the time 
>in  the course of my breakneck two years with 
>OLPC. One such thing is,  after giving a bunch 
>of high-profile talks about systems 
>security,  writing a short one about security 
>and programming languages. The Boston Lisp folks 
>invited me to give the talk[1] on May 27th, 
>so  the audience is a fairly clueful programming 
>crowd without any  necessary prior exposure to 
>language security and capability ideas.  I'll be 
>talking for 25 minutes: covering the basic ideas 
>and looking  briefly at things like E, Joe-E, 
>Caja and CaPerl. Questions for this crowd: * 
>Have you seen any _great_ short introductory 
>capability and    language security talks before?

The one that comes to mind for me is David Wagner's recent talk:

http://youtube.com/watch?v=EGX2I31OhBE
http://www.cs.berkeley.edu/~daw/talks/TRUST07.pdf

That was a 60 minute talk, but I think with a bit less emphasis
on Joe-E (while still speaking briefly and generally about object
safe languages) you might get something similar down to 25 minutes.

>What made them great?
(Continue reading)

Permalink | Reply | 0 comments |
headers
zooko | 4 May 2008 16:51
Gravatar

Re: Security and languages talk

On May 3, 2008, at 8:29 PM, Ivan Krstić wrote:

> * If this was your first brush with the relevant topics, what could
>    I say that would really pique your interest?

One interpretation of the resurgence of capability theory in the last  
decade is this:

For a long time, capability theorists tried to persuade security  
theorists:  "Hey, you guys really messed up, made some basic factual  
errors about capabilities in the 70's, and then you all built careers  
out of inventing alternatives to capabilities which alternatives, it  
turns out, aren't necessary.".

For some reason, this didn't go over very well, e.g. [1].  (I love  
the bit about the flaming sword.  That sounds like Ross Anderson's  
voice.)

Sometime in the early 21st century the capability theorists started  
telling programming language researchers: "You guys have developed  
these wonderful theories of how to build and manage abstractions and  
guess what?  Your ideas can solve security problems as well as  
solving the problems that you started out with.".  This was a much  
more popular pitch.  Security had already become important to  
programming language theorists by then because of the Web (i.e. the  
Mass-Market Internet).

So if I were a programming language expert who had not yet thought  
deeply about security, my interest would be aroused by the notion  
that good security can be implemented as an elegant extension or re-
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jed Donnelley | 4 May 2008 20:36

Re: Security and languages talk

At 07:51 AM 5/4/2008, zooko wrote:
>On May 3, 2008, at 8:29 PM, Ivan Krstić wrote:

> > * If this was your first brush with the relevant topics, what could
> >    I say that would really pique your interest?

>One interpretation of the resurgence of 
>capability theory in the last  decade is this: 
>For a long time, capability theorists tried to 
>persuade security  theorists:  "Hey, you guys 
>really messed up, made some basic 
>factual  errors about capabilities in the 70's, 
>and then you all built careers  out of inventing 
>alternatives to capabilities which alternatives, 
>it  turns out, aren't necessary.". For some 
>reason, this didn't go over very well, e.g. [1].
>[1] http://www.eros-os.org/pipermail/cap-talk/2003-March/001133.html

Occasionally I get new insights from rereading 
such material.  In this case I realize the this from Boebert:

>   As a footnote, Bill Young  of the University 
> of Texas, Dick  Kain, and I  decided shortly 
> thereafter that a distributed protection state 
> was beyond the ability of the verification 
> tools of the time to deal with, and we dropped 
> the PSOS-inspired capability architecture for a 
> more direct implementation of the 
> Lampson  Access Matrix.  This 
> eventually  became  what is  now
(Continue reading)

Permalink | Reply | 0 comments |
headers
David-Sarah Hopwood | 4 May 2008 21:43
Picon

Re: Security and languages talk

zooko wrote:
> On May 3, 2008, at 8:29 PM, Ivan Krstić wrote:
> 
>> * If this was your first brush with the relevant topics, what could
>>    I say that would really pique your interest?
> 
> One interpretation of the resurgence of capability theory in the last  
> decade is this:
> 
> For a long time, capability theorists tried to persuade security  
> theorists:  "Hey, you guys really messed up, made some basic factual  
> errors about capabilities in the 70's, and then you all built careers  
> out of inventing alternatives to capabilities which alternatives, it  
> turns out, aren't necessary.".
> 
> For some reason, this didn't go over very well, e.g. [1].

Let's be clear, though: this view was and is correct. And not only are
the alternatives unnecessary; more importantly, they don't work.

I agree that this may not be the best way to "sell" capability systems
in the short term, but eventually the history will be rewritten, and it
will include our point of view about these errors made in the 1970s. It's
just a matter of time.

--

-- 
David-Sarah Hopwood

_______________________________________________
cap-talk mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matej Kosik | 5 May 2008 11:20
Picon
Favicon

Re: Security and languages talk

Hi Ivan,

I do not know how much my point of view matters but here it is:
(I am sorry for the length)

Ivan Krstić napísal:
> I'm directing much of my recently-gained spare time[0] towards a few  
> things I've wanted to work on for a while, but haven't had the time in  
> the course of my breakneck two years with OLPC. One such thing is,  
> after giving a bunch of high-profile talks about systems security,  
> writing a short one about security and programming languages.
> 
> The Boston Lisp folks invited me to give the talk[1] on May 27th, so  
> the audience is a fairly clueful programming crowd without any  
> necessary prior exposure to language security and capability ideas.  
> I'll be talking for 25 minutes: covering the basic ideas and looking  
> briefly at things like E, Joe-E, Caja and CaPerl.

Most (all?) object-capability languages are at present in a deadlock. They will be used when they
become useful and they will be useful when they become used (because people will find (and fix?)
bugs, contribute with libraries, create awsome programs that will attract other developers. How to
break this deadlock is an interesting question. Certainly, even if these ideas are great, they will
not spread autonomously because the net-effect of the legacy is too strong.

> 
> Questions for this crowd:
> 
> * Have you seen any _great_ short introductory capability and
>    language security talks before? What made them great?
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Rob Meijer | 5 May 2008 20:42
Picon
Picon
Favicon

Re: Security and languages talk

On Mon, May 5, 2008 11:20, Matej Kosik wrote:
> Hi Ivan,
>
> I do not know how much my point of view matters but here it is:
> (I am sorry for the length)
>
> Ivan Krstić napísal:
>> I'm directing much of my recently-gained spare time[0] towards a few
>> things I've wanted to work on for a while, but haven't had the time in
>> the course of my breakneck two years with OLPC. One such thing is,
>> after giving a bunch of high-profile talks about systems security,
>> writing a short one about security and programming languages.
>>
>> The Boston Lisp folks invited me to give the talk[1] on May 27th, so
>> the audience is a fairly clueful programming crowd without any
>> necessary prior exposure to language security and capability ideas.
>> I'll be talking for 25 minutes: covering the basic ideas and looking
>> briefly at things like E, Joe-E, Caja and CaPerl.
>
> Most (all?) object-capability languages are at present in a deadlock. They
> will be used when they
> become useful and they will be useful when they become used (because
> people will find (and fix?)
> bugs, contribute with libraries, create awsome programs that will attract
> other developers. How to
> break this deadlock is an interesting question. Certainly, even if these
> ideas are great, they will
> not spread autonomously because the net-effect of the legacy is too
> strong.
(Continue reading)

Permalink | Reply | 17 comments |

Gmane