Untrusted environment: Difference between revisions

Beware of allowing user input to fed to the reverse polish calculator. It has the ability to run shell commands, and this could be a security risk:

 

 

=={{header|Go}}==

 

The following example shows how to use a combination of reflection and pointer arithmetic to indirectly (and unsafely) change the contents of a byte slice.

 

import (

}

fmt.Println(string(bs))

 

{{out}}

=={{header|Lua}}==

Lua supports protected calls and custom environments. Details have changed through various versions, and the specifics can become quite involved if/as needed, however the following might suffice as a simple example for Lua 5.2 or 5.3.

print("hello") -- safe

for i = 1, 7 do print(i, i*i) end -- safe

sandbox = { print=print }

local ret, msg = pcall(load(untrusted,nil,nil,sandbox))

{{out}}

<pre>hello

GP has a default, <code>secure</code>, which disallows the <code>system</code> and <code>extern</code> commands. Once activated this default cannot be removed without input from the user (i.e., not a script).

 

system("del file.txt");

 

=={{header|Perl}}==

Perl can be invoked in taint mode with the command line option <code>-T</code>. While in this mode input from the user, and all variables derived from it, cannot be used in certain contexts until 'sanitized' by being passed through a regular expression.

 

my $f = $ARGV[0];

open FILE, ">$f" or die 'Cannot open file for writing';

print FILE "Modifying an arbitrary file\n";

 

=={{header|Phix}}==

'''with safe_mode''' disables most potentially dangerous features such as file i/o, and invoking c_func/proc() or using inline assembly outside of Phix\builtins\, which should make it safer to try out code from an untrusted source. It behaves identically to a -safe command line option, however relying on the latter risks leaving a dangerous file lying around that might accidentally be run without the proper command line flag in some idle moment much later, whereas of course if you put it in the source, that's not such an issue.

<span style="color: #000080;font-style:italic;">-- demo\rosetta\safe_mode.exw

--

--#ilASM{ mov eax,1 }

-- The above would be rejected outright by pwa/p2js anyway, with or without safe_mode</span>

Note that builtins\VM\pDiagN.e has to switch it off (eg to write an ex.err file when the program crashes), which is trivial to do but only via #ilASM{}, so a malicious programmer simply cannot, that is, as long as you actually use safe_mode, and don't ever put untrusted code into the builtins\ directory. Special allowances are made for mpfr.e (aka gmp) and pGUI.e (aka IUP), since they're not inherently dangerous; there might be some other libraries that deserve similar treatment.

 

=={{header|Racket}}==

The <tt>racket/sandbox</tt> library provides a way to construct limited evaluators which are prohibited from using too much time, memory, read/write/execute files, using the network, etc.

#lang racket

(require racket/sandbox)

(define e (make-evaluator 'racket))

(e '(...unsafe code...))

The idea is that a default sandbox is suitable for running arbitrary code without any of the usual risks. The library can also be used with many different configurations, to lift some of the restriction, which is more fitting in different cases.

 

For example, given ''cat.rexx'':

 

 

{{out}}

=={{header|Ruby}}==

Ruby handles untrusted input with the global variable <code>$SAFE</code>. Settings higher than 0 invoke an increasing level of sandboxing and general paranoia.

$SAFE = 4

cgi = CGI::new("html4")

 

=={{header|Rust}}==

=={{header|Tcl}}==

Tcl allows evaluation of untrusted code through ''safe interpreters'', which are evaluation contexts where all unsafe operations are removed. This includes access to the filesystem, access to environment variables, the opening of sockets, description of the platform, etc.

Because the only way that Tcl code can perform an operation is by invoking a command if that command is not present in the execution context then the functionality is gone.

 

It is possible to profile in restricted versions of operations to allow things like access to built-in packages.

These work by installing aliases from the otherwise-removed commands in the safe interpreter to implementations of the commands in the parent master interpreter that take care to restrict what can be accessed. Note that the majority of unsafe operations are still not present, and the paths supported to the packages are virtualized; no hole is opened up for performing unsafe operations unless a package author is deliberately careless in their C implementation.

 

 

Variable references should be contained in double quotes to prevent an empty string causing an error as a result of omission during evaluation:

 

=== Do not allow users to run programs that can launch a new shell ===

However, the restricted shell is not completely secure. A user can break out of the restricted environment by running a program that features a shell function. The following is an example of the shell function in vi being used to escape from the restricted shell:

 

:set shell=/bin/sh

 

=== Use a chroot jail ===

 

Sometimes chroot jails are used to add a layer of security to

cd ~/jail;

chroot ~/jail;

setuid(9); # if 9 is the userid of a non-root user

 

=={{header|Wren}}==