At Mon, 5 Nov 2018 16:26:16 -0600, Alexis King wrote:
> To provide an example, `racket/contract` exports a value called
> `the-unsupplied-arg`, which is created using the usual structure type
> generativity trick:
>
> (define-struct the-unsupplied-arg ())
> (define the-unsupplied-arg (make-the-unsupplied-arg))
> (provide the-unsupplied-arg)
>
> The constructor is not exported, and this value is intended to be unique.
> However, if we can arrange for the contract library to be loaded on our
> terms,
> we can thwart this encapsulation by supplying it with a weaker inspector:
>
> #lang racket/base
>
> (define the-unsupplied-arg
> (parameterize ([current-inspector (make-inspector)])
> (dynamic-require 'racket/contract 'the-unsupplied-arg)))
>
> (define-values [info skipped?] (struct-info the-unsupplied-arg))
>
> (define another-unsupplied-arg ((struct-type-make-constructor info)))
>
> (equal? the-unsupplied-arg another-unsupplied-arg) ; => #t
> (eq? the-unsupplied-arg another-unsupplied-arg) ; => #f
Later parts of the thread have touched on this, but the general rule is
that if you control the environment where code is loaded, then you can
do anything to that code. After all, if you get to pick the
environment, then you could use an interpreter that you wrote from
scratch and that gives you whatever capabilities you want.[*]
If you don't control the environment of `racket/contract`, then you
might not be able to break in this way. It depends on how the
environment is set up, though. If `racket/contract` is loaded before
your code, then it's too late to change the inspector, but maybe you
can load `ffi/unsafe` and still do whatever you want. Or maybe your
code is prevented from loading `ffi/unsafe` directly due to a
code-inspector change, but some sandbox bug or a bug in a trusted
library lets you get access to unsafe operations anyway.
Chaperones and inspectors provide a set of ground rules for access, and
`the-unsupplied-arg` is unique for a setting that respects those rules.
A program can subvert the rules through outside control or through
environment weaknesses. We've tried to build mechanisms that absolutely
enforce the rules, and it works well enough for some purposes, but
offering real guarantees turns out to be impractical for now.
It seems possible that if a sandbox is working right and if unsafe
operations are truly inaccessible, then maybe currently a chaperone is
enough to guard against even a superior inspector. But that doesn't
seem like a good solution to me. Instead, it makes me think that there
should be an operation that lets a sufficiently powerful inspector pull
apart chaperones.
[*] There's some work on encrypted computation where the environment
executing some code can't know everything about the code. I'm guess
that's not where you're trying to go, though.
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
