Untrusted environment: Difference between revisions

→‎{{header|Phix}}: removed incomplete tag, and documented the new safe_mode handling.
(→‎{{header|Phix}}: removed incomplete tag, and documented the new safe_mode handling.)
Line 164:
 
=={{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.
{{improve|Phix|Implement this and add a "phix --safe" option.}}
Phix makes no attempt to protect anyone from untrusted code or inputs from untrusted users. <br>
However, in theory it would be reasonably straightforward to build a "crippled" version of phix that makes malicious activity all but impossible.
 
See demo\rosetta\safe_mode.exw for the remnants of a development testbed for this feature. 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.
The most dangerous construct is #ilASM{} (inline assembly), but it should not be difficult to prohibit that except in builtins\ and builtins\VM\ by adding a guard such as
"if fileno>2 then ?9/0 end if" at the start of procedure ilASM() in pilasm.e. Obviously you simply never put any untrusted code in either of those directories.
 
Standard disclaimer applies:<br>
The next most dangerous facility is file I/O, for that I might suggest putting similar but run-time guards in builtins\VM\pFileioN.e which get the calling routine number
Everything this relies on was added for this task in less than 24 hours.<br>
from the call stack and then the file number from the symbol table (see [[Stack_traces#Phix]]), and then check that is <=3, ie the above two and the main phix directory,
In no way do I even begin to think this is secure or complete, but just
since obviously you don't want to cripple I/O for the compiler itself, and in turn that means any untrusted code has to be put in some other directory.
yesterday (at the time of writing) it was 100% totally insecure: there
 
was no "with safe_mode" option, no -safe command line option, nothing
Similarly we have system/system_exec(), c_func/proc(), and call(), all of which you would probably want to disable from untrusted code. <br>
at all to check or even store that option in the compiler, or runtime.
Lastly I would recommend having a think about disabling libcurl, SQLite, etc, but that's a bit beyond my remit, and I should reiterate from the perl entry that a proper physically separate/expendable sandbox is probably the better idea, when possible.
Should you want this to be improved, simply add more tests to demo\rosetta\safe_mode.exw, and
obviously complain if/should they not entirely meet your expectations.
 
=={{header|Racket}}==
7,795

edits