Re: Pony talks about Deny Capabilities

On 12 May 2015 at 05:54, Dan Connolly <[email protected]> wrote:
>
> 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.

This is very interesting.

> while the main program linking to anything is like the privileged scope

I like this. I suspect this is the route to take for Pony.

I think it's still interesting to be able to deny packages that use FFI (as
ponyc --safe=... already does) for cases like the Pony sandbox:

http://sandbox.ponylang.org/

Here, we allow web users to compile arbitrary main programs. Given that the
main program is the privileged scope, we still want to be able to say such
sandbox programs can have access to the "time" package, but nothing else
that uses FFI (for example). This is similar to limiting what can be
imported from Java in E.

> 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).

My current thought on how to do this is to use the Env passed to Main to
include a checkable "root" authority. That would allow a package that uses
FFI (or any package, though in the absence of FFI I'm having trouble
thinking of a use case?) to define its own set of capabilities, with the
full set made available only to possessors of a "root" authority, otherwise
requiring them to be passed in.

> the message-passing stuff may necessitate using promises or the like.

Pony is actor/message based, so this part isn't problematic. Promises and
capabilities-secure reflection are in the design stage now.

-s

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