Extensible Security Architectures

For Java

Dan S. WALLACHDIRK BALFANZDREW DEAN

EDWARD W.FELTENPrinceton University 1997

presented by Haipeng Wu 29 may 2001

Outline

• Introduction

• Security in Java

• Approaches

• Conclusion

• Question

Introduction

• As the growing of world wide web, mobile code system has raised serious security concerns, since its increased exposure to potentially hostile code.

• This paper explain three different approaches to securely support mobile code on real world

system and their implementations in Java.

Inflexibility of Java Sandbox

Java sandbox (base on JDK1.0 version)• Prevents untrusted code from using any sensitive

system resource. • All file system access is forbidden, and network access

is only allowed to the host where the applet originated.• It applied equally to all applets, was too inflexible to

implement many desirable “real” application.

Approaches

There are three approaches illustrated for resolving

the inflexibility of Java sandbox in this paper

• Capabilities• Extended stack introspection• Name space management

I will briefly introduce the first two approaches and

focus on the third one.

Capabilities

• Design - “Capability is an unforgeable pointer to a controlled system

resource”. - “any program which has a capability must have been

permitted to use it.”

• Implementation in Java - by providing exclusive interface to system resources, hidden

file-related Java class from program or make these class

have non- public constructor. This would requires significant change in Java runtime libraries • Only suitable for applications where programs are not

expecting to use standard Java API.

Extended Stack Introspection

Design• Define a target for the protected resource.• The system check the privilege of target before accessing the

protected resource.

Implementation in Java• By using three functions: enablePrivilege(target)

disablePrivilege(target) checkPrivilege(target)• When program wants to access protected resource, it must first

call enablePrivilege()on the target to get an enabled privilege on this target. After access the resource the program call disablePrivilege() to discard the enabled privilege.

checkPrivilege(target) use to search an enabled privilege.• Offers good compatibility with existing Java applets.

Name Space Management

• Design Enforce a given security police by controlling how

names in a program are resolved into runtime classes.

• Implementation in Java Implemented through modifying the Java ClassLoader.

• Offers good compatibility with existing Java applets.

Name Space Management(cont.)

Design• Use Java classes to represent resources we wish to

control.• Replace the sensitive classes with compatible ones,

which hide the original classes from the remote code.• Use configuration which is a mapping from class

names to implementations.

Java class Alice Bob

Java.net.Socket Security.Socket Java.net.Socket

Java.io.File Security.File ----

Name Space Management(cont.)

Implementation in Java• In Name Space Management it replace each Java

AppletClassLoader with a PrincipalClassLoader.

HTML page with java appletFoo.java

“FileSystem” PCL “FileSystem”, Alice

SubFileSystem class SubFileSystem class “SubFile System”

FileSystem fs = new FileSystem();File f = fs.openFile(“foo”);InputStream s = new InputStream(f);…

…<applet codebase = … code = Foo.class>…

System

Alice

PolicyEngine

Conclusion

• Capability system are only suitable for applications where programs are not expecting to use standard Java API.

• Both Extended stack introspection and Name space management offers good compatibility with existing Java applets.

• The best solution is to combine elements of these three techniques.

Question

• In name space management is it possible to rename the classes which are shared among different Java classes without breaking things ?