bash $ reap_some_code | grep file | more > result ... bash $ cat the_same_code | grep exec >> result bash $ cat the_same_code | grep socket >> result bash $ wc result bash $ more resultA nicer way would be to have a for instance tree based analysis of everything which leads to something potentially dangerous before running, and then having everything happening outside a safe interpreter presented and checked first.Or for instance limiting file access, like to one dir, and not allowing program execution and net access more than for instance some predefined ways or no more than a certain amount, or with permission asking.
One of the things I would at least be concerned with for general use, like running client scripts on request on a web server application, is that it is very easy to do someting like this:
proc getpasswords {} { [find password files] # just file read stuff, could look ok # at general glance } proc send {message IP_address portnr} { #regular stuff, maybe ftp from tcl package } proc obscure {} { set a se set b nd set c getpas set d swords return "$a$b \[$c$d\]" } # and then go: eval [obscure]Of course this wouldn't happen normally, but for instance for a general user program allowing external access and scripting (which is handy) this is unacceptably dangerous.And of course obscuring can be done in thousands of more or less clear and malicious ways.Curse, flame, support, deny, suggest or comment at will, of course...
KBK (16 June 2003)- Safe interpreters are not an all-or-nothing proposition. If you load the Safe Base [1], you get an extremely flexible and configurable security policy. For instance, restricting file system access to a single directory, or restricting Net access to the server or domain from which the Tclet came, is trivial. The Safe Base comes with Tcl - you don't need to download or install anything extra