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

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!