Re: Evaluation with function whitelist

[Ryan Raymond]

Mike, you are truly a lifesaver. My work uses an in-house programming
language that really is not too great, but now I finally have a chance to
change their minds. Thank you so much! This appears to do exactly what I
need.
Dr. Arne, I will certainly use sandboxed evaluation as you have suggested.
I wasn't able to use it to enter a new lexical scope, but it will be good
to protect things beyond that (like infinite loops).
David, Goblins looks interesting. The code you wrote is so elegant. It
looks nothing like corporate code. The premise of the project is
interesting. I'll have to look into it. It's sort of bending my mind (a lot
like lisp at first).

Thank you, all. I think it's safe to consider this matter concluded!
Ryan


On Sat, Jul 15, 2023 at 9:09 AM Thompson, David <dthompson2@worcester.edu>
wrote:

> Hey Ryan, Mike, Arne,
>
> On Sat, Jul 15, 2023 at 6:48 AM Dr. Arne Babenhauserheide
> <arne_bab@web.de> wrote:
> >
> > Mike Gran <spk121@yahoo.com> writes:
> >
> > >>good choice. Basically, I want the user to be able to open a repl
> shell,
> > >>but by default it should have *no* bindings except the ones I
> whitelisted.
> > > Define a module in a file with the "#:pure" option so that it starts
> off empty.
> > …
> > > Using the real repl is probably a no-go, since it has meta-commands
> > > like ",m" that would let the user ignore your whitelist.
> > >
> > > I didn't really test this, but it should be mostly correct.
> >
> > Sandboxed Evaluation may also be interesting for this:
> >
> https://www.gnu.org/software/guile/manual/html_node/Sandboxed-Evaluation.html
> > (to prevent users from blocking the process)
>
> Yeah, I agree that (ice-9 sandbox) is the best option available right
> now.  Not bulletproof but covers a lot of important details that just
> using a pure module would not.
>
> This might be a difficult exercise for someone new to Guile, but the
> 'eval-in-sandbox' procedure looks like it provides the essential piece
> for a sandboxed REPL. You could define a custom language (see (system
> base language)) that uses that procedure as its evaluator. You'd then
> write a script that runs a REPL via (system repl repl) using that
> custom language.
>
> Guix's bournish shell (and monad REPL) does this trick:
>
> https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/bournish.scm#n267
> So does Spritely Goblins (I wrote this code):
> https://gitlab.com/spritely/guile-goblins/-/blob/main/goblins/repl.scm#L206
>
> Neither use sandboxing, but they should serve as good examples of the
> basic "custom language that is just Scheme with a different evaluator"
> + REPL pattern.
>
> I'd be curious to what extent sandboxing would break metacommands, and
> which metacommands could circumvent the sandbox.  One easy, but hacky,
> option would be to just punt on figuring that out and clear the
> command table:
>
>     (set! (@@ (system repl command) *command-table*) '())
>
> > If you want a long term view for the most powerful approach that
> > preserves allow-listing, see Spritely Goblins:
> >
> https://spritely.institute/files/docs/guile-goblins/latest/A-simple-greeter.html
>
> It is not currently safe to evaluate untrusted code with Goblins, and
> it doesn't sound like Ryan is trying to build a distributed network
> application so probably Goblins isn't a good fit. However, it is on
> the Spritely roadmap to write a secure Scheme subset (codename Oaken,
> see https://spritelyproject.org) built on object capability security
> principles.  Oaken would be hosted on the Guile VM.  When that's ready
> I will happily encourage its use.  For now, (ice-9 sandbox) is the way
> to go if Ryan wants to proceed with using Guile.
>
> tl;dr: I think Ryan could make this work.
>
> Good luck with your project, Ryan!
>
> - Dave
>