Design of Extensible Security Architecture for Java of Extensible Security Architecture Design of Extensible…

Download Design of Extensible Security Architecture for Java of Extensible Security Architecture Design of Extensible…

Post on 11-Jun-2018

212 views

Category:

Documents

0 download

Embed Size (px)

TRANSCRIPT

  • 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: mehediku@hotmail.com

    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:mehediku@hotmail.com

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

    the media [2]. Javas 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

  • Design of Extensible Security Architecture

    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

    Load PolicyConfiguration

    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

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

    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.

  • Design of Extensible Security Architecture

    3.3.1 Security Check Algorithm The security check takes place in side

    Security Managers 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

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

    19

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

    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 foun...

Recommended

View more >