[racket] Handin Server + PLAI problem [and 1 more messages] [and 2 more messages]

Perhaps the right thing is to have the setup code export a small
library that contains a "is my mark bound in the context" function and
then the sandbox can call that function when deciding whether or not
to grant permission.

(That has the dependencies going the right way, right?)

It doesn't get us really any steps closer to the more general solution
but perhaps it is enough for this discussion to end?

Robby

On Sat, Jan 14, 2012 at 9:41 PM, Eli Barzilay <eli at barzilay.org> wrote:
> Just now, Robby Findler wrote:
>> On Sat, Jan 14, 2012 at 9:23 PM, Eli Barzilay <eli at barzilay.org> wrote:
>> > The sandbox shouldn't be the place for that -- it would be a
>> > reversed dependency, where the setup (core) code depends on a
>> > library.  But in this case it's not only a "shoudln't" -- it's a
>> > "cannot": see the comment at the top of
>> > "setup/private/main-collects.rkt" about why it shouldn't depend on
>> > anything.
>> >
>> > But it would also not be right to just add some parameter to the
>> > main-collects code, since that would be visible and usable by any
>> > code to bypass security checks.
>>
>> I think that security-guards and continuation marks are a good way
>> to build a high-level capability permissions model in Racket. I
>> would have thought that the sandbox would be a good library to
>> include that in, but maybe we should be doing something smaller that
>> the sandbox just uses? (Is that what you're saying?)
>
> Yes, I think so.  I think that most of a "capability permission model"
> is already there in the form of security guards, except that it's very
> simple, and this case is one that needs some solution that goes beyond
> that simplicity.
>
> As for the implementation, I don't think that any general thing should
> go into the sandbox code, since security guards can be used
> independently too[*].  But the two concrete problems of any kind of a
> solution would be the dependency issue (and given that the
> main-collects is very core-ish, this code would need to be core-ish
> too), making sure that no other code can fake its way out of a
> security guard (which I don't know how to solve).
>
>
> [*] I do see a way to justify such code in the sandbox library: remove
> all of the security features and have only the sandbox interface.
> IOW, if you want to use just the security guards, you'll need to use a
> sandbox for that.  On one hand, this is tempting, since currently
> there's a ton of little details in dealing with all of the different
> settings (which makes the sandbox code be what it is), but on the
> other, it also has another important side which is the evaluator.  So
> IMO doing something like this would be better as two libraries: one
> for all security aspects, and one for all evaluator needs, then the
> sandbox would be a simple (ha!) combination of the two.  But all of
> this is not practical for actually changing any code...
>
> --
>          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
>                    http://barzilay.org/                   Maze is Life!