This article was slightly edited for spelling by lvirden@cas.org by request of the author. Newsgroups: comp.lang.tcl Path: chemabs!malgudi.oar.net!caen!saimiri.primate.wisc.edu!ames!agate!pasteur!sprite.berkeley.edu!asah From: asah@sprite.berkeley.edu (Adam Sah) Subject: Tcl'93 Future Directions Session 3 notes. Message-ID: <1993Jun13.184606.12638@pasteur.Berkeley.EDU> Sender: nntp@pasteur.Berkeley.EDU (NNTP Poster) Nntp-Posting-Host: treason.berkeley.edu Organization: University of California, at Berkeley Date: Sun, 13 Jun 1993 18:46:06 GMT Lines: 133 What follows are notes I made during the "Future Directions" session #3, led by John Ousterhout, during the Tcl'93 Workshop. Each session had a "main topic" of discussion, plus an open period where he solicited random suggestions for improving the language. Main topic: security. --------------------- I. John's slides (these are more or less verbatim from his slides- the peanut-gallery commentary is at the bottom) 1. Evaluating Untrusted Scripts - cover 2. Introduction goal: use tcl scripts as a gen. purp. method of interchange: - among app's on a display. - active email (eg. surveys) security problems: - tcl is powerful (file access) - evil scripts can do great harm. solution: - twin interpreters (like user/kernel space in os's) - protected calls between them (like system calls) 3. Twin Interps - trusted interp- used by app/user: has full access to all tcl cmds - untrusted interp- used to exec incoming (suspicious) scripts- all dangerous cmds removed. - new cmds in trusted interp: set evil [safetcl create] $evil eval $script - untrusted interp won't be able to do much that's useful, though. 4. Safe Calls Allow untr. interp to impl. restr'd new fun's for untr. interp: - restr'd file access, sending mail... - analogous to system calls. Mechanism: cmd in untrusted interp that causes exec of cmd in trusted interp. - in trusted interp: set evil [safetcl create] $evil safecall sendmsg checksend - in untr'd interp: sendmsg $to $body - subst's must occur in untr'd interp! - checksend exec'd in tr'd interp with fully-subst'd args. - result/error retn'd to untr'd interp. 5. Safe Calls (cont'd) Proc's that impl. safe calls must be very careful: - never eval arg as tcl script or tcl expr! - check filenames before read/write files. - never exec shell cmds specified in args w/o careful checking first. - when in doubt, ask user for permission (but not too much, or else this technique loses effectiveness, as users are constantly saying "OK" to everything) result: safe calls hard to write and certify. but, for max power, wants lots of safe calls avail. need mechanism for certifying and distributing safe calls. 6. Certifying Safe Calls Use encryption techniques (digital sigs): - central, trusted, netw auth. writes new safe calls, certifies them with dig. sig, distr's publicly. - anyone can fetch cert'd safe calls, check sig, install locally w/o fear. - active email msg (untr'd) can contain new safe calls as part of untr'd script. - untr'd script invokes existing safe call to make new safe call - in tr'd interp, verify sig of incoming safe call before installing. Can extend mech. to have local cert. auth's as well as global. 7. Other apps Safe Call mech. suitable for many other things besides active email: - restrict incoming 'send' cmds in tk. - in commercial product, restrict access by customers to internal cmds. - in device control apps, don't allow users total control over devices (could be dangerous) II. Comments (where possible, I made a note of who said what, so followup is possible- if no name is present, then it means that I didn't catch the speaker quickly enough...) John: example of GUI for untrusted Tk apps: have untrusted windows be children of trusted windows in Tk- then add speckled border to mean "don't trust me!", plus a 'kill' button that always gets rid of window (which would also handle the 'grab' problem...) - resource limits on untrusted interp? (ie. disk, cpu, mem usage?) - John: safety is more important than resource limits (which most OS's still handle ok w/o security holes) - Karl: _never_ call eval on stuff from untrusted script (based on his implementation) - John: must strip _all_ I/O (otherwise untrusted script could generate it's own file handle, etc.) ==> ok to make untrusted interp separate process (the argument that file handles aren't valid across process boundaries isn't valid- you wouldn't want to give away real file handles anyway) - Adam: important to have test suites for security- won't stop new holes, but will stop old and common holes from appearing as a result of new features/changes. - active email can install new safecalls- safe calls can be "autoloaded" from a well-known site storing them (via email)- ie. in active email, if a msg is dependent on a safecall not installed locally, you'd get a "waiting for script..." msg and the new script could be telnet'd, ftp'd, or email'd... - need multiple levels of trust (alternate trusted sites and sources) - experiences from MIME- the 1st released version must be good enough, because commercial sites might not be able to receive these updates. good enough= useful for 99% of all stuff, ie. active msgs. - auditing/logging of active email etc.? - Adam: have an _unsafe_ call library, not just a safe call lib- question of whether it makes more sense to have large libraries of safe calls, or large lib's of unsafe calls (latter will be slower to exec, since need checking, but former are more prone to sec leaks and need verification etc.) - templates for active email (a standard form called a "survey" and users can declare options for how it will look and behave within that style). misc: - Wayne Christopher: hard to debug 'trace' if there's an error in the trace procedure. someone: use "after 1" to get you out of that. - can't rerun error msgs. - need: error msg after write traces. - need: access to value _before_ write traces. John: diff to impl. - an "unknown" for variable access. - use of % subst in var traces - events on all sorts of error (user defined events). userdef error codes (long discussion on how to implement. John suggests that the numeric error codes could be generated at runtime by a routine, rather than by #defines. Adam: be careful- they then can't be passed to other wish's! John: string error codes? - rename as an event?, return callbacks for procedures? - pass args by name not position to proc's? Thanks again, -A.Sah'93 ...Adam Sah...asah@cs.Berkeley.EDU... It's not the voltage, it's the amperage.