120 likes | 134 Views
This paper discusses approaches to secure mobile code in Java, addressing the inflexibility of the Java sandbox. It covers capabilities, extended stack introspection, and namespace management, highlighting their designs and implementations in Java. The conclusion recommends combining the techniques for optimal security.
E N D
Extensible Security Architectures For Java Dan S. WALLACH DIRK BALFANZ DREW DEAN EDWARD W.FELTEN Princeton University 1997 presented by Haipeng Wu 29 may 2001
Outline • Introduction • Security in Java • Approaches • Conclusion • Question
Introduction • Asthegrowing 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.
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 ?