Check out the new USENIX Web site. next up previous
Next: Conclusions Up: Building a Secure Web Browser Previous: Browser Interpreter Daemon

Related Work

  Web browser security is topic that has received a great deal of attention since its so crucial in today's highly interconnected computing. However there have not been any satisfactory solutions so far. The primary proposed solution is secure interpreters for JavaScript, VBScript, Java, etc. [14,15,17,10,9]. Such solutions fail because of their complexity. The more complex the implementation, the more likely it is to have bugs. Furthermore they don't address the issue of other helper applications like Perl or Tcl. When they are invoked, the user is asked to give a blanket ``go'' ``no-go'' response, and this puts a lot of burden to the user.

Another language related technique used for ensuring security is code verification. This approach uses proof-carrying code [16] to demonstrate the security properties of the object. This means that the object needs to carry with it a formal proof of its properties; this proof can be used by the system that accepts it to ensure that it is not malicious. Code verification is very limiting since it is hard to create such proofs. Furthermore, it does not scale well; imagine creating a formal proof for every Web page.

A different approach relies on the notion of system call interception, as used by systems such as TRON [5], MAPbox [4], Software Wrappers [7] and Janus [8]. TRON and Software Wrappers enforce capabilities by using system call wrappers compiled into the operating system kernel. The syscall table is modified to route control to the appropriate TRON wrapper for each system call. The wrappers are responsible for ensuring that the process that invoked the system call has the necessary permissions. The Janus and MAPbox systems implement a user-level system call interception mechanism. It is aimed at confining helper applications (such as those launched by Web browsers) so that they are restricted in their use of system calls. To accomplish this they use ptrace(2) and the /proc file system, which allows their tracer to register a call-back that is executed whenever the tracee issues a system call. These systems are the most related to our work; however, our system differs in a major point. We view every object as a separate user, each with its own sub-user id and access rights to the system resources. This sub-user id is attached to every incoming object when it is accepted by the system, and stays with it throughout it's life, making it impossible for malicious objects to escape.


next up previous
Next: Conclusions Up: Building a Secure Web Browser Previous: Browser Interpreter Daemon
Sotiris Ioannidis
4/28/2001