Secure execution of Java applets using a remote playground

Abstract

Mobile code presents a number of threats to machines that execute it. We introduce an approach for protecting machines and the resources they hold from mobile code, and describe a system based on our approach for protecting host machines from Java 1.1 applets. In our approach, each Java applet downloaded to the protected domain is rerouted to a dedicated machine (or set of machines), the playground, at which it is executed. Prior to execution the applet is transformed to use the downloading user's web browser as a graphics terminal for its input and output, and so the user has the illusion that the applet is running on her own machine. In reality, however, mobile code runs only in the sanitized environment of the playground, where user files cannot be mounted and from which only limited network connections are accepted by machines in the protected domain. Our playground thus provides a second level of defense against mobile code that circumvents language-based defenses. The paper presents the design and implementation of a playground for Java 1.1 applets, and discusses extensions of it for other forms of mobile code including Java 1.2.

Globule: A Platform for Self-Replicating Web Documents

“…This problem will be solved with classical techniques such as executing remote code in a sandbox or a remote playground [8].…”

Contrasting Malicious Applets by Modifying the Java Virtual Machine

“…The basic idea of this approach is to setup a sacrificial machine with only minimum connections to the rest of the net, and execute all Java code on it [13]. While this approach can certainly be used to put a limit on the damage a malicious applet can wreak, it also foregoes the ability to use the Java language for distributed computing, and it feels like a step back.…”

Processes in KaffeOS: Isolation, Resource Management, and Sharing in Java

“…An alternative approach to achieve isolation between different applications is to give each one its own virtual machine, and run each virtual machine in a different process in an underlying OS [23,27]. For instance, most operating systems can limit a process's heap size or CPU consumption.…”