Version 0 of Secure code method thinking

Updated 2003-06-16 11:57:03

Theo Verelst

While putting up my utility pcom on the wiki for cut and paste, I was thinking about security, not so much because it greatly bothers me to cut-and-paste some wiki gem or other thing into an interpreter to see what it does and enjoy, but because it seems like a good idea to have at least something to program in or script in which CAN be safe like lets say Java can be started in a browser, anticipating its security settings and the VM download and internals are such that nothing malicious will happen almost for certain.

For pasting into a tcl interpreter, I guess one could use a safe interpreter, which I didn't thus far come to use very much (for no particulalry articulate reason), but for some serious programs one would want file and net access.

A simple solution could be:

 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 result

A 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...