[Fwd: Re: [plt-scheme] Stack inspection security]

David Van Horn <dvanhorn at cs.uvm.edu> writes:

>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
> [ Meant to send this to the list ]
>
> John Clements wrote:
>> First off, I'm guessing you're not familiar with my paper on this topic:
>> 
>> A Tail-Recursive Semantics for Stack Inspections
>> http://www.ccs.neu.edu/scheme/pubs/esop2003-cf.pdf
>> 
>> ... which shows, among other things, how to implement stack inspection
>> using continuation marks.
>
> No, I'm actually quite familiar with it; that's where I got the idea for stack
> inspection using continuation marks.  But the \lambda_{sec} language abstracts
> over what a principal is.  The annotator consumes a peice of source code and
> it's permissions, but where do these permissions come from?  In an
> implementation, a policy would map principals to privileges, and the runtime
> would need to mark any peice of code as belonging to some (unforgeable)
> principal (or at least this is how it is done in the JVM & CLR).  My post was
> intended to ask, "what's a principal in PLT Scheme?", which seems relevant if
> PLT is going to allow code to be downloaded and run from the internet.

If we identify the `sandbox environment' as the principal, then the policy
would be the environment constructor.  The runtime would mark the code as
belonging to the `sandbox' principle by simply closing the lambda expressions
in that environment.  Right? 

>> I for one would be more inclined to try to set up a capability-based system for security.

I assume you've read Jonathan Rees'es paper?