Re: Pony talks about Deny Capabilities

On Mon, May 11, 2015 at 12:29 PM, Sylvan Clebsch <[email protected]> wrote:
>> From: Dan Connolly <[email protected]>
>> I'm looking over the standard library for ambient authority... the
>> main(env: Env) gave me hope, but now I see:
...
>> and @os_listen_tcp
...
> Obviously, access to C breaks the ocap model entirely. However, we're hoping
> the --safe mechanism gives a usable trust boundary. This is an area we are
> very keen to have feedback on.

One idea I had when I started looking at rust is: let main programs
link to whatever the developer likes, but don't let libraries
(including the standard library) link to ambient authority. Libraries
have to act like emakers:

  Emakers have an important security property: they come to life
contained in a world with no authority.
   -- http://wiki.erights.org/wiki/Emaker

while the main program linking to anything is like the privileged scope
  http://wiki.erights.org/wiki/Walnut/intro

So the constructor for actor TCPListener would need the @os_listen_tcp
capability passed in explicitly (perhaps using a vtable, i.e. struct
of function pointers... though I have already forgotten the details of
the pony type system relevant to whether this is feasible).

>> and File new create(path': String)
>
> Yeah. File systems. Ugh. This is a huge ambient authority problem, and we
> don't have a clear idea of how to handle it better.

As others have said, the Joe-E/elib/Emily API works reasonably well;
any such API (where all authority is explicit) lets you exploit
capability support at the O/S level using openat() and the like or use
message-passing to stuff such as capsicum, capnproto, etc. ... though
the message-passing stuff may necessitate using promises or the like.

-- 
Dan Connolly
http://www.madmode.com/