[cap-talk] Lua, Javascript, and the Object Capability Model

[Matej Kosik]

Hi James,

James Graves wrote:
> Matej Kosik <kosik at fiit.stuba.sk> wrote: 
> 
>> Lua probably supports sandboxing. Untrusted code is started in a context
>> where dangerous functions are undefined.
> 
> Yes.  When you are initializing a new Lua instance in C code, you
> explicitly bring in the standard libraries.  However you can chose
> what to put into the instance's environment.
> 
>> Does it also support dynamic changes in the reference graph according to
>> object-capability security model? I.e. connectivity:
>> - by initial conditions
> 
> Yes, as above.
> 
>> - parenthood
> 
> Yes.  For example, if you create a new object (table), that is the
> only reference to it.  You cannot forge a local reference from inside
> Lua code.
> 
>> - by introduction
> 
> Yes, in the same Lua instance, if you've got a reference to an object
> (data, function, module, etc.) you can give that as a result of a
> function call.

Suppose that you have two separate confined subsystems and one has
access to a function defined in another one. The following two questions
might be silling but I would like to ask anyway:

(1) Can the first subsystem pass a reference to its private object to
another subsystem as a parameter to a function call?

(2) Can the second subsystem return a reference to its private object to
the first subsystem as a return value?

> Or write it back into your environment, which can be 
> be later read by your parent.
> 
>> - by endowment
> 
> Yes, you can pass in whatever you've got in your environment into a
> child environment.  You can also pass in objects via the function
> parameters when starting the child environment... which is technically
> 'introduction' I suppose.

(This is an interesting answer to a different question. See the first
two questions. We can return to it later.)

> 
>> I guess not but because if you want to call a function in Lua, you
>> specify (forgeable) name. That name is looked up in appropriate
>> hash-table. Untrusted subsystems may have different hash-tables. I am
>> not sure though whether it is possible to realize "connectivity by
>> introduction" in this system. There are certain useful security policies
>> that cannot be implemented if this is not possible.
> 
> I'm not quite sure what your point is here.
> 
> Names are just entries in your environment, which is either
> function-local or your envionment.  And your parent can modify your
> environment in any possible way.
> 
> So you have to trust your parent, but isn't that always the case?

(This is an interesting answer to a different question. See the first
two questions. We can return to it later.)
-- 
Matej Kosik