The safe-tcl mailing list has not been active for a few months. I think a lot of interest has transferred to Java. One problem is that safe-tcl was oriented around email, so it lacks facilities for accessing web pages. I agree with Ray that the security of safe-tcl leaves something to be desired. I implemented a safe-tcl mail filter which would automatically run incoming mail scripts which were in safe-tcl format. This would be a generalization of a remailer, so that users could write scripts which would determine when the remailing would occur, etc. However I ran into a number of problems, particularly related to persistent storage (e.g. disk file access). This is a hard problem for a "safe" system to solve. One solution is to just forbid it, but beyond that you need to have rules about how much disk space a script can use, whether they can access each other's space, etc. There are some nice applications if they can do so, for example the telescript model where two software agents come together and exchange some information. Another tricky issue is if you are going to let the script talk to the outside world via email or tcp connections. How do you prevent abuse of this feature (sending junk email, or connecting to a web page and entering bogus data into a form)? But again, without this capability the script is pretty much limited to drawing pretty pictures on your screen, which isn't very useful. Here is one message I sent to the safe-tcl list earlier this year describing some of these problems in a little more detail. Note that there were also several bugs in the implementation which left security holes, things being checked in the wrong context and such. This is similar to what Ray was citing. Hal
From owner-safe-tcl@CS.UTK.EDU Fri Feb 10 22:30:35 1995 X-Resent-To: safe-tcl@CS.UTK.EDU ; Sat, 11 Feb 1995 01:22:02 EST Date: Fri, 10 Feb 1995 22:21:28 -0800 From: Hal <hfinney@shell.portal.com> To: safe-tcl@CS.UTK.EDU Subject: setconfigdata and delivery time Status: R
The spec appears to allow delivery-time scripts to do setconfigdata. This is a mechanism for a script to store persistent data. One application would be a telescript-like interaction between scripts. Some data could be stored by one script and later read by another. More interesting, a script could even store some script, perhaps some or all of itself, into this persistent store. That script could then be read and eval'd by a later script. This way scripts could in effect call subroutines in each other, providing somewhat similar functionality to telescript's procedure calls between agents.
At activation time the user gets asked whenever a script does getconfigdata, although oddly not when a script does setconfigdata. Also, the .safetcl.conf file is written on any getconfigdata after the user has supplied or confirmed a database value. This will have the side effect of writing out any setconfigdata values which have been previously set by the script.
At delivery time the current implementation will not ask the user since there is no user to ask, which causes the writing out of the config data base never to happen. So there is actually no way for a delivery time script to set a persistent value right now. It would be easy to change the code to allow delivery time scripts to set persistent values with setconfigdata.
However, this does open up a possible avenue for abuse. There is presently no limit on how much data is written with setconfigdata. And actually if the idea above were used where scripts put themselves into the database for later running then the database could legitimately be quite large. The problem would arise if a script abused this capability by filling the disk with junk database entries.
Maybe something is needed analogous to AutoConfirmMailHook to determine whether a given SafeTcl_setconfigdata should be able to go out to the disk. It would want to be given the data as input and possibly also the size of the current database. Maybe there should be a counter of how many times the current script has written to the database (or perhaps the hook could retain this information itself).
Two other points: as mentioned before the use of the database to retain "system" information conflicts with its use for this purpose. If database entries like "mailer" or "external-site" are changed and saved to .safetcl.conf, that could break later invocations of swish. I think this system data should be somewhere else (or else there needs to be another form of persistent store for scripts).
Secondly, the code right now checks the SafeTcl_evaluation_time variable in the restricted interpreter to decide whether it should ask the user. This is not reliable as the untrusted script could change SafeTcl_evaluation_time. In other places the code checks SafeTcl_InterfaceStyle and if it is empty then it doesn't ask. That seems safer.
Hal Finney hfinney@shell.portal.com