design of extensible security architecture for java … of extensible security architecture design...

Design of Extensible Security Architecture

Design of Extensible Security Architecture for Java Applets

Ehsan Masud1, Md. Mahbubur Rahman2, Md. Mehedi Masud2

1Bpro Inc, SD, USA 2Computer Science and Engineering Discipline

Khulna University, Khulna Bangladesh

Email: [email protected]

Abstract

With the advent of technology,

information sharing has become much more rapid and important. World Wide Web has been used to build increasingly complex applications even though the development was constrained by the static document model of Web. Development of variety of mobile code systems such as Java, JavaScript, ActiveX eliminates the constraints faced by the Web application developer due to prior static document technique. Increasing popularity and acceptance of such mobile code systems have shifted the gravity of Web into a platform for writing complex mission critical applications, from its origin of simple HTML documents. On the other hand, these mobile codse or remote codes, which run inside the environment supplied by the browser, raises serious security threats. To address these security threats traditionally mobile code technology such as Java, JavaScript, ActiveX generally maintain a restricted security policy. There is a trade off between the openness desired by the Web application

writer and security level imposed by the browser. In this work Java has been chosen as mobile code technology, as there are more Java Applets on the web than any other mobile code applications. This paper presents software-based extensible security architecture for Java Applets and proposes new model for Java Applets to support negotiation between the user and Applet.

Key Words: Applet, WWW, Browser, JVM

1. Introduction Java is a portable, secure, object-

oriented language that is suitable for software development projects of all size [1]. Sun Microsystems developed Java and released it, along with a World Wide Web browser named HotJava that was implemented entirely in Java, in the late spring 1995. Since then, the Java programming language has been the focus of an incredible amount of attention from developers, software companies, and from

International Journal of The Computer, The Internet and Management, Vol. 11, No.2, 2003, pp. 15 - 23

15

mailto:[email protected]

Ehsan Masud, Md. Mahbubur Rahman, Md. Mehedi Masud

the media [2]. Java’s growth over the last couple of years has been nothing short of phenomenal. The only similar examples of such rapid growth are the Internet itself and the World Wide Web [3].

The continuing growth and popularity of

Internet has let to a flurry of development for the World Wide Web. Many content providers had expressed frustration with their inability to express their ideas in HTML. For example, before support for table, many pages simply used digitized picture of table. As quickly as new HTML tags are added, there will be demand for more [4]. Rather than creating new HTML extensions, Sun Microsystems popularized the notion of downloading a program (called Java Applet) which runs inside the browser. Such remote code raises serious security issues. The role of security is to protect the machine that runs a Java application from damage that can be done by the program intentionally or unintentionally. In the case of the later, it is desirable that a poorly written program not causes the machine to crash because of such things as mismanaged pointers or memory. In the worst case, a malicious program can attack the local file system or operate inside a network firewall.

2. Statement of the problem Rogue Java applets are currently a major

concern for big companies and private user alike. While the best protection against them is to turn off Java support of browser. This solution is unsatisfying since it deprives us of many advantages of Java platform [5].

Traditional sandbox security in Java has

focused on two separate fixed security policies. Local code, loaded from specific directory on the same machine as the JVM, is completely trusted. Remote code, loaded

across a network from arbitrary source, is completely untrusted. The sandbox security model is easy to understand, but it prevents many kinds of useful programs from being written. All file system access is forbidden, and network access is only allowed to the host where the applet is originated. While untrusted applets are successfully prevented form stealing or destroying users’ files or snooping around their networks, it is also impossible to write a replacement for users’ local word processor or other common tools which rely on more general networking and file system access. It is clear at this point that “all or nothing” security model is inadequate. What is needed some intermediate point between “anything goes” and “confined in the sandbox” access. Java Applet security model can be extended to provide something in between of the above two extreme situation. Instead of putting an Applet into sandbox we could deny access to certain parts of the system resources according to some static predefined or dynamically decided policy by the user.

3. System Architecture

3.1 Overview of the Architecture Browser provides the runtime Java

environment for Java Applets. Browser again an application, which runs in operating system, provided by the native machine. Since the Browser runs in the native machine as any other local application it has the power experienced by the user on the machine. The Browser has the full capability to access and modify the local system as any other local application. Java Applets are foreign application loaded by the Browser either from the network or from the local machine. These foreign applications cannot be fully trusted. Traditionally they are put in restricted environment, called sandbox, to

16


isolate the local operating environment and that supplied by the browser to the Applets. Due to these restrictions useful Applets are not possible. So there is a trade off between the security level imposed on the foreign Applets and power of writing useful Applets endorsed by the Browser environment or by the local operating environment. The objective of this paper is to propose software based extensible security architecture for Java Applets. Extensible means the level imposed by the Browser environment could be changed or modified or increased or decreased after the initial system was shipped from the industry. We move the further of the word extensible, the security level can be settled even after the Applet is

loaded into the browser environment. For settling the security level we used two mechanisms. One is fixed and other is dynamic. The fixed security level is set by the user or by the system administrator before hand the Applets are loaded into the browser environment or even before the browser environment is loaded into the local operating environment. The dynamic security level is settled by negotiating mechanism between the user and the Applet itself. To incorporate security negotiation mechanism we proposed a new model for the Applets, which is of course backward compatible with the existing model for the Applets.

Browser Sysetm Code

Browser Environment

Applet Classes

Message Transfer

Security Negotiation

Applet ClassLoader

Applet SecurityManager

Get Permissionsfor Classes

Internet/IntranetStandard Java

Library

Security CheckMethad CallLoad Applet

Classes

Policy ObjectConsults Security

Level

Serialized Binary Objectfor Disc File

Serialized Binary Objectfor Policy Server Security Negotiation

Load PolicyConfiguration



Applet Classes

International Journal

Figure 1 : Browser Environment

of The Computer, The Internet and Management, Vol. 11, No.2, 2003, pp. 15 - 23

17


3.2 Browser Environment Browser provides the runtime Java

environment for the Applets. Browser environment composed of the following, as shown in figure 1.

• Browser System Code • Graphical Component Container to

hold Applets

Browser system Code is the heart of the browser. Browser system code could be written in native language (such as Netscape or Internet Explorer) or could be written in Java (such as HotJava browser). If it is written by native language it loads standard Java runtime environment for the Applets. We followed the later technique. In our work we have chosen to develop the browser system code in Java. So it does not need to load separate Java runtime environment for the Applets. The Browser is loaded as a standard Java local application in the Java operating environment supplied by the native operating environment. In this case Browser system code and the Applets share the same Java runtime environment supplied by the native operating environment. All code that comes with the browser is browser system code. Browser system code is composed of the following components:

•

• • • •

Main Control Module (top level Graphical User Interface) Applet Security Manager Applet Class Loader Policy Object Security Negotiation Mechanism

All of the above are designed to be

included as Java runtime library extensions. Java virtual machine treats Java runtime library extensions as system classes and they are loaded by primordial class loader, which is actually the absence of any class loader.

3.3 Applet Security Manager AppletSecurityManager is a subclass of

SecurityManager which is in java.lang package of standard Java library. It allows an application to determine, before performing a possibly unsafe or sensitive operation, what the operation is and whether the operation is being performed by a class created via a class loader rather than installed locally. Classes loaded via a class loader (especially if they have been downloaded over a network) may be less trustworthy than classes from files installed locally. The application can allow or disallow the operation.

The SecurityManager class contains

many methods with names that begin with the word check. These methods are called by various classes in the Java libraries before those perform certain potentially sensitive operations. The invocation of such a typical check method is shown in the following figure:

oppopesecretulocthedefin Thloc

18

SecurityManager security = System.getSecurityManager(); if (security != null) { security.checkXXX(argument,…);
}
Figure 2: Checking security strategy The check method is thereby given an

ortunity to prevent completion of the ration by throwing an exception. A urity manager check method simply rns if the operation is permitted by the

al policy, or throws a security exception if operation is not permitted. The initions of all the checkXXX methods are

the AppletSecurityManager class. erefore checkXXX methods enforce the al security policy.


3.3.1 Security Check Algorithm The security check takes place in side

Security Manager’s checkXXX(…) methods. Below is the algorithm for making security decision for Applets. The algorithm work by inspecting the Java stack. It loops newest to

oldest class in the current execution stack and looks for class or classes loaded by AppletClassLoader (Sec. 3.4). If one or more classes is found loaded by AppletClassLoader it checks whether the class has the said permission.

boolean checkAppletForPermission( permission) { //loops newest to oldest class in the currentexecution stack for each classInStack { if(classInStack is loaded by AppletClassLoader) if(local policy does not have the permissionfor classInStack) return false;

}
Figure 3: Security check algorithm
boolean insideSecurityManager( classesInStack[]) {

//loops newest to oldest class in the currentexecution stack for( i = 1 to classesInStack.length) { // classesInStack[0] is the SecurityManager class if(classesInStack[0] == classesInStack[i]) return true; // a security check is beingdone

} return false;

Figure 4: Accessing security information


19


3.3.2 Privilege Handling When one security check is in progress

there should not be any further security check. Such as an Applet might want to access a file in local system, consequently a checkRead(..) method will be invoked. Inside the checkRead(..) method the security decision will be made. In taking the decision the system code must access local file system or make network connection to policy server to get the local policy which the Applets do not have permission to read. Say we have the local policy in the local file system. Again checkRead(..) method will be invoked, this method call should not throw a security exception even the Applet class in the current execution stack do not have the appropriate permission to read the file or make network connection to policy server. The later code is privileged code. In this circumstance if we examine the current execution stack will find two occurrences of SecurityManager class, that indicates that a security check is in progress. The algorithm for handling this scenario is shown in figure 4.

3.4 Applet Class Loader One aspect of the Java Virtual Machine

is the class loader architecture. A class loader is used to implement a policy for loading Java classes. In the Java Virtual Machine, class loaders are responsible for importing binary data that defines the running program's classes and interfaces. In Java linking is done at runtime. Whenever execution of Java byte code requires the presence of a new class (e.g. because one of its method is invoked), then the new class loader is invoked to fetch the class material (the class file). It is up to the class loader how to get the class material. Browsers have special class loader, normally called Applet class loader.

For each class it loads, the JVM keeps track of which class loader loaded the class and when a loaded class refers to another class, the virtual machine requests the referenced class from the same class loader that originally loaded the referencing class. Each class loader creates a name space for the loaded classes. Class loaded by a particular class loader can see the classes loaded by the same class loader and the system classes. All the system code is loaded by a primordial class loader, which is an absence of class loader, actually null class loader. The system code is the standard Java libraries and all Java library extensions. The applet class loader loads all the Applet classes. So from any class, the class loader that loaded it can be found. From the class loader we can find the code source of the class. Sending the code source to Policy Object the permission set associated with the class can be found. Access control decision will be made from this permission set in side the Applet Security Manager checkXXX methods. 3.5 Policy Object

PolicyObject is a subclass of Policy

class of java.security package of standard Java library. java.security.Policy is an abstract class for representing the system security policy for a Java application environment (specifying which permissions are available for code from various sources). That is, the security policy is represented by a Policy subclass providing an implementation of the abstract methods in this Policy class.

PolicyObject is the repository of

permission set for different classes. Classes are identified by CodeSource class of java.security package of standard Java library. PolicyObject provides methods to get/set collection of permission for a given

20


CodeSource. How the local policy is stored is

implementation dependent, Java provides abstract Policy class but the implementation of this class is rendered to the policy provider. In this work PolicyObject class provides the solid implementation for the Policy class. PolicyObject stores it configuration as serialized binary object. Serialization provides mechanisms for reading and writing object’s state. The key to writing an object is to represent its state in a serialized form sufficient to reconstruct the object as it is read. We provide two mechanisms for loading and saving policy.

• Serialized object to/from local file

system • Serialized object to/from Policy

server The AppletSecurityManager consults

PolicyObject to determine the current security level. Permissions are stored in PolicyObject with correspondence with the

code source associated with classes. AppletSecurityManager gets the code source of any class from the class loader loaded the class. PolicyObject gets the dynamic security level information from security negotiation.

3.6 Security Negotiation Statically (i.e., before the Applet is

loaded into the Browser environment) fixing the security level is good for the Applets we have enough information regarding the source and the specification. But the Applets are designed to be found on the web, it is highly likely that the user will browse Applets they don’t have enough information. In that case it is required to fix the security level through negotiation between the user and the Applet before it starts running. There are two mechanism for this

• Eager evaluation • Lazy evaluation

BrowserEnvironment AppletSecurity

Negotiation

Applet SendsRequest Object

Browser SendsApproved Object

Figure 5 : Security Negotiation


21


In lazy evaluation, whenever there is a need to access a protected system resource by the Applet, a negotiation between the user and Applet takes place for that particular permission. In the eager evaluation the security level is fixed before the Applet starts its actual operation. In this mechanism the Browser environment hence the user have the idea before hand, what are the system resources the Applet is going to access, on the contrary the Applet has the knowledge of what are the privileges are granted to it. Either the Browser or the Applet might want Negotiation Exception. to discontinue operation by throwing a Negotiation Exception.

3.6.1 New Model for Applet to Support

Security Negotiation To support security negotiation we

propose new model for Applets. Traditionally Applets have four methods, init(), start(), stop(), destroy() all of these methods are called by the Browser. When the Applet is first loaded the Browser call init() method, where the Applets do all of its initialization work. After the Browser call start() method, then the actual operation of the applet is started. The stop() method is called by the Browser when the user leaves the HTML document contains the Applet, this does not unload the Applet from the Browser environment. When the user comes back to the same page the Browser again call the start() method. The Browser unloads the Applet from the memory by calling destroy() method. In the new model we include

another method named negotiate(). The signature of the method shows in figure 6.

It is the only method of Negotiable

interface. This method called by the Browser in the process of security negotiation. Approved and Request class encapsulate the permissions requested by the Applet and those are approved by the Browser hence the user respectively (Figure 3.2). Browser makes several methods call to settle the security level for the Applet. Either the Browser or the Applet might disagree by throwing a Negotiation Exception.

4. Conclusion Originating from simple static document

model World Wide Web has evolved to a new platform for developing complex mission critical application which is possible partly because of the advent of mobile code systems such as, Java Applet, JavaScript, ActiveX Component. Mobile code is downloaded in to the local system and run inside the environment supplied by the Web browser. The paper addresses the security issues concerning with the Java Applets.

Traditionally Java Applets run is a

restricted environment to eliminate the security threats to the user and it prevents all such attacks successfully, except few implementation bug in Java virtual machine or in Web browser. On the other hand due to the restricted environment development of

public Request negotiate (Approved approved);

Figure 6 : Signature of negotiate method

22


application was painful and sometimes impossible to develop useful applications. This work accounts both the user and developer point of view. The security level is fixed with the concern of the user and the Applet. User has given an option to statically set security level and on the contrary the Applets has the option to negotiate the security level with the user through sophisticated graphical user interface.

The local system security level or policy

is represented as persistent object, options have been added to load/save the state of the object into local file system and in to policy server, which is very useful if the local system lacks file system security and also centralized management of security policy is possible. This work provides protection mechanism for Java Applets, there are many other mobile code systems such as JavaScript, ActiveX components, there will be more in near future and they are getting increasingly popular, we expect future work to provide combined frame work of protection mechanism against all these mobile code systems. The security negotiation presented in the work can be improved incorporating software agent theories. The work presents class level protection mechanisms, which can be extended to object level protection mechanism.

References

[1] Gosling, G., Joy, B. and Steele, G., The Java Language Specification (First Edition) 1996 by Addison-Wesley, 1996.

[2] Groner, D., Sundsted, T., Hopson, C.,

and Prabanham, H., Java Language API SuperBible, The Waite Group, 1996

[3] Harold, E.H., Java Secrets, Hungry

Minds Inc,1997. [4] McGraw, G. and Felten, E., Java

Security: Hostile Applets, Holes and Antidotes, John Wiley and Sons, New York, 1996,

[5] Wallach, D. S., Balfanz, D., Dean, D.

and Felten, E.W., “Extensible Security Architectures for Java”, Proceedings of 16th Symposium on Operating Systems Principles (Saint-Malo, France), October 1997


23

design of extensible security architecture for java … of extensible security architecture design...

Documents