A page to discuss the usefulness of safe interps,
and things related (such as what to ensure about your
extension to make it 'safe' (see also the [safe] command.

I'm starting this page with a very informative post from
[The comp.lang.tcl newsgroup] by [Jacob Levy]. Feel free
to add more!
----

I don't think the example Tcl code you gave is a security problem because "exec" is not available in a safe interpreter, and neither is "source". So this example cannot be done in a safe interpreter.

Anything available in a safe interpreter (when it is first created) is safe for that interpreter. Note that I said "available", hidden functions (ones whose name is given in a call to "interp hide") are not available in the safe interpreter. All dangerous stuff like "exec" and "source" is hidden by "interp create -safe". After that, if the user does not add native code packages or "interp expose" or "interp alias", then the interpreter stays safe. The interpreter stays safe even if you do these things, but carefully. The master interpreter is able to relax security to a degree, under its control, by making more functionality available in the slave safe interpreter through aliases.

In general, a native code package should not violate this rule, so a slave safe interpreter should be as safe with the functionality of this package as it is without it. For more relaxed security, use security policies first introduced with the Tcl plugin. Note that by design, if the package is written in 100% Tcl code it is safe because all Tcl primitives that are unsafe are not available in the safe slave interpreter and thus it matters nought if the code tries to use them; they will just fail.

So the question to be asked by a security review of Itcl is: is Itcl safe enough so that it can be added to a safe interpreter and not compromise the base security policy provided by "interp create -safe". If not, you should write some other mechanism that only allows adding Itcl to the safe slave under control of an explicit security policy. Of course as Itcl provides functionality implemented by native code, that mechanism is going to look awfully much like the SafeInit, but it will be some other API accessible only under control of the master interpreter.

For an example of a safe native code package, my very own e4Graph (http://e4graph.sourceforge.net) package has a SafeInit function that makes the package available in a safe interpreter and only does not make the "tgraph::open" function available. The reasoning is that "tgraph::open" would allow the safe interpreter to open new storages, use arbitrary on disk files, etc. Clearly a security violation. Instead, storages are explicitly shared with the slave safe interpreter by its master through "tgraph::transfer". The rest of the functionality *is* safe because the safe interpreter can not obtain access to storages that it wasn't given access to, only to storages that have explicitly been shared with it by its master. Yes, the safe slave interpreter could do arbitrary damage to the storages that the master chose to share, but that's a calculated risk that the master interpreter decided to take. I consider this risk not to be serious, on the same order as the risk taken by the master when "interp transfer"ing Tcl I/O channels into a slave safe interpreter. The end conclusion is that the safe slave interpreter is as safe with as it is without the provided functionality.

On the other hand, if you want to give a safe slave interpreter access to sockets, the risks are more serious. In that case we need to implement a way to protect resources outside of Tcl on the local machine from serious damage, ideally making them inaccessible to the untrusted code. So for that you could use the "outside" security policy that Laurent Demailly and I wrote for the Tcl plugin. This policy protects the local machine against programs running on other machines, but allows the interpreter to communicate with those programs by opening sockets on ports on those machines. The slave safe interpreter cannot open sockets on ports serviced by the local machine, so it cannot connect e.g. to your smtpd to send hate mail from your machine. But it can connect to nearly anything off of your machine. This is a calculated risk that the master interpreter chose to take: while it protects your local machine from damage, it does not protect your reputation from damage.

Now I'm not too sure how to parse the following, in light of the presence of "Init" (and now "SafeInit") procedure for Itcl:  Itcl does nothing with system calls.  100% Tcl API -- mostly related to scope." I suppose you mean, yes, it is not written purely in Tcl, but all the APIs provided by the C code have to do with ... etc. That is,

I agree that Expect should not have a SafeInit.

--JYL