Untrusted environment: Difference between revisions
→{{header|Phix}}
Thundergnat (talk | contribs) m (→{{header|Perl 6}}: argh. spelling) |
|||
Line 113:
Really, if you want to lock down a Perl 6 instance so it is "safe" for unauthenticated, untrusted, general access, you are better off running it in some kind of locked down virtual machine or sandbox managed by the operating system rather than trying to build an ad hoc "safe" environment.
=={{header|Phix}}==
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.
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.
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
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,
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.
Similarly we have system/system_exec(), c_func/proc(), and call(), all of which you would probably want to disable from untrusted code. <br>
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.
=={{header|Racket}}==
| |||