Re: Pony talks about Deny Capabilities

On Mon, May 11, 2015 at 12:46 PM, Sylvan Clebsch <[email protected]
<https://mail.google.com/mail/?view=cm&fs=1&tf=1&[email protected]>>
wrote:

> On 11 May 2015 at 20:04, Mark Miller <[email protected]
> <https://mail.google.com/mail/?view=cm&fs=1&tf=1&[email protected]>>
> wrote:
> >
> > Agree with Scott. But see also how previous ocap languages running on
> unmodified legacy non-ocap OSes handled these issues, including E, Joe-E,
> and Emily. See also how Caja/SES handles access to ambient browser
> authority such as the DOM.
>
> E's approach (assuming I understand it correctly, which is a big
> assumption) of only allowing a File object to be created relative to a
> previously existing File object is the one I've been looking at (funnily
> enough, just this past weekend).
>

Essentially, yes.

E approached this problem by starting with the Java APIs, which already put
an oo skin over the various OSes, and therefore saved us much work. We then
"only" had to close the gap between their oo principles and ocap
principles. Although you are not starting with Java, you should be able to
learn lessons from this effort.

See:
https://code.google.com/p/joe-e/wiki/Taming
http://www.combex.com/papers/darpa-review/security-review.html#taming
http://www.erights.org/elib/legacy/taming.html

Compare:
http://erights.org/javadoc/java/io/File.html
vs
http://www.cs.berkeley.edu/~daw/joe-e/api/java/io/File.html




> I was considering a separate sort of object that encapsulated a Path,
> which could be examined, split, etc as usual, but a new Path would have to
> be a concatenation of an existing Path and additional data.
>
> This would allow a "root" Path to be passed in the Env to the Main actor,
> with that actor then able to control access in the expected way. Is that
> the approach you are advocating, Mark?
>

Yes.



>
> However, Scott's points about atomic creation, etc, would still be
> unaddressed.
>

Without help from the OS, there's only so much a language can do.




> Scott, thanks for the pointer to Shill, I'm sorry to say I hadn't come
> across it previously. I'll read up!
>

Good. Highly recommended!



> Another issue I've been thinking about is that if a file system sandbox is
> a capability, and perhaps network access (though addresses are less
> usefully hierarchical - although DNS perhaps is), then is some more general
> mechanism for a package introducing a new "root" capability (not previously
> encoded in Env, but necessarily not ambient) needed? Is there existing work
> in this area?
>

IIUC, see
http://erights.org/elang/io/uri-exprs.html
with
http://www.erights.org/data/serial/jhu-paper/exit-security.html
as an example of unprivileged user code creating new uri "roots".

Though I am not sure I understand your question.
Is this the kind of thing you have in mind?

-- 
  Cheers,
  --MarkM

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk