in reply to Extending a perl program with Scheme, Lua, or JS

Thanks, all, for the helpful advice and pointers!

I've ended up deciding to go with Guile via a shell, at least for the time being. Here is my glue code. Guile meets my criteria of being installable as a debian package, having good performance, being stable and actively maintained, supporting data structures, and having simple syntax.

Although I think the possibility of a Trojan horse attack using Guile code embedded in a document is realistically a little remote due to my small user base plus sociological factors, I'm looking into how to sandbox Guile. Guile has a sandbox mechanism that seems to be only focused on preventing excessive use of resources. I've posted on the guile-user email list to ask if there's any way to prevent code from accessing the file system and such. I could also just turn off Guile extensions by default.

  • Comment on Re: Extending a perl program with Scheme, Lua, or JS

Replies are listed 'Best First'.
Re^2: Extending a perl program with Scheme, Lua, or JS
by haukex (Archbishop) on Feb 12, 2019 at 09:37 UTC
    Here is my glue code.
    use strict; package Extension; sub apply_scalar_function_of_x { my $f = shift; # lisp source code, with x as the input, e.g., "* x 0 +.1" # As a convenience feature, if $f is undefined or nul +l string, we return the input unaltered. my $x = shift; if (!defined $f) {return $x} my $lisp = "(display ((lambda (x) ($f)) $x))"; my $result = `guile -c '$lisp'`; if ($? == 0) { return $result; } else { print STDERR "Error executing scheme code $lisp using guile."; return undef; # occurs if guile is not installed or the guile code + dies with an error } # to do: # Escape single quotes inside the string. } 1;

    Unfortunately, as discussed, this suffers from multiple potential injection and quoting issues. In this case, I would recommend either IPC::Run3 (libipc-run3-perl) or IPC::System::Simple (libipc-system-simple-perl) - the former is probably better if this software is supposed to run on Windows too. If you don't want to install an extra module, then you could use the piped open I show near the bottom of my post here.

    use IPC::System::Simple qw/capturex/; sub apply_scalar_function_of_x { my $f = shift; my $x = shift; if (!defined $f) {return $x} my $lisp = "(display ((lambda (x) ($f)) $x))"; my $result; if (not eval { $result = capturex('guile','-c',$lisp); 1 }) { print STDERR "Error executing scheme code using guile.\n"; return; } return $result; }
    I'm looking into how to sandbox Guile. ... if there's any way to prevent code from accessing the file system and such.

    Yes, I would very strongly recommend not leaving an open source grading system open to attacks ;-)

      Thanks, I've redone the code as you suggested: https://github.com/bcrowell/opengrade/blob/master/Extension.pm

      However, Scheme is a general-purpose programming language, and as I've pointed out previously, this feature is designed to run user-defined scheme code. So there's no need to do injection or quoting. If you're a malicious person writing a Trojan horse, the thing to do would be simply to put the malicious code in there, and if you can get someone to open your file, it will run. Nothing else can fix this unless Guile can be sandboxed. Protecting against injection and quoting would become helpful only if there was also sandboxing. I've asked in a couple of places for suggestions on how to sandbox Guile:

      http://lists.gnu.org/archive/html/guile-user/2019-02/threads.html#00025

      https://stackoverflow.com/questions/54640307/sandboxing-guile-by-deleting-unwanted-libraries

      No replies yet. It may just be necessary to turn off the extension mechanism by default, and let users know that if they activate it, they will be running arbitrary code from any person who gives them a file to open.

Re^2: Extending a perl program with Scheme, Lua, or JS
by bliako (Abbot) on Feb 12, 2019 at 11:58 UTC
     my $result = `guile -c '$lisp'`;

    I would put the full path to guile there..., or compile a guile without system()+friends support, make it static and you have some kind of sandbox. The latter is theoretical and requires better skills than mine because it seems guile's scm_system() is required for its own compilation...

      Thanks for the suggestions. Unfortunately I don't think this is practical. The path for guile will be different on different systems, so I can't just hardcode it. If someone has the ability to get on my desktop system and put a malicious binary named, say, ls in my home directory, I'm kind of screwed no matter what.

      I also don't want to get into the business of maintaining and distributing my own sandboxed version of guile, nor do I want potential users to have to install such a thing just so they can use my code; one of my design criteria is that the program should not have any dependencies that are not available as debian packages. If I had the relevant time and knowledge of the Guile codebase, I think the thing to do would just be to offer the Guile folks a patch with an option like -s to run it sandboxed, and get that patch accepted into the standard version of Guile. But I think that would be jumping the gun, since I don't even know yet whether there is some easy, standard way to sandbox Guile.