Joey Rozier

April 7, 1998

The use of programs from unknown sources is becoming more prevalent as the use of the Internet spreads. Using such programs makes the issue of security very important, since an applet from an untrusted source should not be allowed to access the memory and network capabilities of the client it is running on. One mechanism to allow the use of untrusted programs (applets) without compromising security is the Safe-Tcl system developed at Sun Microsystems Laboratories. The developers of Safe-Tcl chose a celled structure, in which an application allows the applet to run using one of a variety of security models. By giving the flexibility of multiple security models, Safe-Tcl has the benefit of allowing the user to restrict applets to perform certain functions depending on the trustworthiness of the author. The main disadvantage of using this system is that a security model may be developed that is not as secure as the user expects, so that they are lulled into a false sense of safety.

The main benefit of allowing multiple security models for a Safe-Tcl applet is that the user can give an applet only enough permission to perform the tasks that are absolutely necessary, depending on how much the user trusts the source. A fully trusted source can therefore be given full access to the user's system, while an untrusted source cannot perform any direct memory or network accesses. The user can even specify specific mixes of security measures for different sources-for example, restricting one applet to only file access and memory access, while giving another applet only the ability to write files and read from the network. This fine-grained level of access control, although more complex than a single security model, gives the user the power to decide how much they trust any given applet, allowing trusted applets to perform very useful features that would be ruled out in a single security model.

The Safe-Tcl security model has a major risk, though, in that a security model used by the user's application may not be entirely safe. One way this could happen is if a malicious user provides an application with intentionally faulty security methods. The user would then install this application, and applets could gain access they are not supposed to have. Another more likely scenario is if a system administrator develops a security system without testing it thoroughly. Because of the complex interactions of potentially restricted activities (such as file I/O and network access), it is possible that a person developing a given security system would fail to see a security hole that an applet could later exploit. In both cases, the user may believe that they are only providing an applet with a small subset of access privileges when they may be granting it considerably more. The problem is that the user believes he has a secure system, which makes him less "on guard" for such breaches.

Safe-Tcl provides a convenient way of maintaining fine-grained security control over programs, whether trusted or untrusted. The extensibility of the security system makes it attractive in a system where applets that may perform useful tasks safely exist alongside malicious applets. There is a risk in the system, though, in that allowing such extensibility makes the possibility of a security bug significant-whether malicious or unintentional.