java外文文献

Computer Communications 23 (2000) 1594±1605

On object initialization in the Java bytecode q

S. Doyon *

, M. Debbabi

LSFM Research Group, Department of Computer Science, Laval University, Sainte Foy, Que., Canada G1K 7P4

Abstract

Java is an ideal platform for implementing mobile code systems, not only because of its portability but also because it is designed with security in mind. Untrusted Java programs can be statically analyzed and validated. The program's behavior is then monitored to prevent potentially malicious operations. Static analysis of untrusted classes is carried out by a component of the Java virtual machine called the veri®er. The most complex part of the veri®cation process is the data¯ow analysis, which is performed on each method in order to ensure type-safety. This paper clari®es in detail one of the tricky aspects of the data¯ow analysis: the veri®cation of object initialization. We present and explain the rules that need to be enforced and we then show how veri®er implementations can enforce them. Rules for object creation require, among other things, that uninitialized objects never be used before they are initialized. Constructors must properly initialize their this argument before they are allowed to return. This paper also deals with initialization failures (indicated by exceptions): the object being initialized must be discarded, and constructors must propagate initialization failures. q 2000 Elsevier Science B.V. All rights reserved.

Keywords: Java bytecode; Object initialization; Data¯ow analysis; static analysis; java security

1. Introduction

The Java architecture is particularly well-suited for implementing mobile code systems. A mobile code archi-tecture allows a computer to fetch a program (or parts of a program) from a network source and execute it locally. However, security is a critical aspect of mobile code archi-tectures. The very essence of mobile code is to execute a program that originates from a remote source. This is inher-ently dangerous because it is not known what actions that program will take. By executing the mobile code, we are allowing it to perform operations on our machine and we are giving it access to our local resources.

Java is especially well-suited for implementing mobile code systems for three reasons:

²Java source is compiled into a platform-independent intermediate form called Java bytecode. Java byte-code is then interpreted by the JVM (Java virtual machine).

This makes Java bytecode completely portable, which means a piece of Java code in compiled form should run on any receiving machine.

q The research reported in this paper has been supported by the National Science and Engineering Research Council (NSERC), the Fonds pour la formation de chercheurs et l'aide aÁ la recherche (FCAR), and the Defense Research Establishment Valcartier (DREV), Department of National Defense.

*Corresponding author. Tel.: _1-41-8656-7035; fax: _1-41-8656-2324.

E-mail address: ²It is dynamically linked: the JVM will load classes from different network sources as they are needed and will link them into the program while it runs.

²The Java architecture is built with security in mind: its design makes it possible to enforce suf®cient security to make mobile code safe and practical.

Currently, the most popular manifestation of Java mobile code is applets. A JVM (bytecode interpreter) is incor-porated in web browsers. Web pages can then include links that point to the compiled (bytecode) form of programs which are called applets. The applet can then be loaded by the browser and executed locally with no special effort on the user's part.

The veri®er is a key component of the Java security archi-tecture. Its role is to examine compiled classes as they are loaded into the JVM in order to ensure that they are well-formed and valid. It checks that the code respects the syntax of the bytecode language and that it respects the language rules. Another component of the Java security architecture, called the security manager, monitors access to system resources and services. The security manager is a security layer, which goes on top of the veri®er and relies on its effectiveness.

The most complex step of the veri®cation process performed by the veri®er requires running a data¯ow analy-sis on the body of each method. There are a few particularly tricky issues regarding the data¯ow analysis. In this paper, we focus on the issues relating to the initialization of

0140-3664/00/$ - see front matter q 2000 Elsevier Science B.V. All rights reserved. PII: S 0 1 4 0 - 3 6 6 4 ( 0 0 ) 0 0 2 4 5 - 0