The evolution of Java security - IBM · The evolution of Java security by L. Koved A. J. Nadalin D. Neal T. Lawson This paperprovides a high-leveloverview ofthe development andevolution

The evolution of Javasecurity

by L. KovedA. J. NadalinD. NealT. Lawson

This paper provides a high-level overview of thedevelopment and evolution of Jeve" security.Java is a maturing technology that has evolvedfrom its commercial origins as a browser-basedscripting tool. We review the various deploymentenvironments in which Java is being targeted,some of its run-time characteristics, the securityfeatures in the current releases of the basetechnology, the new Java Development Kit(JDWry 1.2 policy-based security model,limitations of stack-based authorization securitymodels, general security requirements, andfuture directions that Java security might take.IBM initiatives in Java security take into accountour customers' desire to deploy Java-basedenterprise solutions. Since JDK 1.2 was enteringbeta test at the time this paper was written,some operational changes and enhancementsmay result from industry feedback by the timeJDK 1.2 becomes generally available.

T he software industry is focused on providing sup-port for developing and deploying mission-crit-

ical applications written in Java**. The Java envi-ronment encompasses a broad spectrum fromenterprise servers to embedded devices. A range ofJava-based systems, including JavaOS**,Embedded-Java**, and PersonalJava**, among others, will be-come available, providing potentially different lev-els of underlying services. This situation will resultin requirements for varyinglevelsof security strength.

The initial focus of Java security has been in the sup-port of downloaded applets (small programs) withinWorld Wide Web browsers. To a large extent, thesecurity features in Java reflect this heritage. As Javamatures, it will increasingly support additional se-

curity features to address the needs of the target ap-plication environments. Included is the addition ofsecurity features generally found in large-scale serverapplications.

We have seen examples of howe-business (businessconducted electronically via the Web) increases acustomer's reach byorders of magnitude. As the cus-tomer base increases, the absolute magnitude oflosses from malicious behavior can become greatenough to warrant improved security products de-ployed in information technology systems. However,should a security exposure become widelypublicized,a customer's reputation can become tarnished. IBM'scustomers demand systems implementations that arenearly flawless and that address the needs of theirenterprise. They look to IBM to ensure that risks areknown and to respond quickly with action when ex-posures are uncovered.

Gartner Group's December, 1996, report, Java-Good Start, but Not Yet Secure,' highlights severalareas of concern regarding Java security that arebased on earlier versions of the Java DevelopmentKit (JDK**). Realistic expectations are important:no system is 100 percent secure. However, it is cru-cial to recognize three things about Java security:

©Copyright 1998 by International Business Machines Corpora-tion. Copying in printed form for private use is permitted with-out payment of royaltyprovided that (1) each reproduction is donewithout alteration and (2) the Journal reference and IBM copy-right notice are included on the first page. The title and abstract,but no other portions, of this paper may be copied or distributedroyalty free without further permission by computer-based andother information-service systems. Permission to republish anyother portion of this paper must be obtained from the Editor.

IBM SYSTEMS JOURNAL, VOL 37, NO 3, 1998 0018-8670/98/$5.00 © 1998 IBM KOVED ET AL. 349

1. Java enables a function that was never beforecommercially deployed on a broad scale: dynamicloading of code from a source outside the system.This important feature aggravates a significant"Trojan horse" security problem. However, it alsoprovides extremely valuable function.

2. Java security was not designed to solve the sameproblems as the Resource Access Control Facil-ity (RACF*) function in the Operating System/390(OSI390*) Security Server addresses on MultipleVirtual Storage (MVS*), or similar traditional en-terprise security technologies. RACF is designedto protect the enterprise and its resources againsthostile users. The security for Java is designed toprotect the user's workstation and resourcesagainst hostile code.

3. RACF and other traditional enterprise securitytechnologieswork wellbecause they assume-andtheir environments provide-strong operatingsystemintegrity as a foundation. Java also assumesthis integrity; however, the predominant desktopoperating systems do not provide it sufficiently.

Security technologies are needed to prevent or mit-igate the following types of threats:

• Unauthorized resource usage, including theft of soft-ware or CPU usage, corruption of data and soft-ware, disclosure of information, and unaccount-able action

• Abuse ofprivilege, including misrepresentation ofidentity, affiliation,value of items exchanged, andentitlement of services; impersonation; fraud; andextortion

• Malicious code, including protection from viruses,worms, Trojan horses, and logic bombs

• Wiretapping, including active and passive measures• Denialofservice, includingdestruction of resources,

saturation of services, and interruptions of com-munications

Trojan horse and spoofing attacks have been themost common Java security threats publicized todate. Once identified, it has been relatively easy toprovide fixesas the majority of attacks have occurreddue to implementation errors in browsers or in Javarather than fundamental design flaws.

Java security foundation and evolution. Since ini-tial commercial deployments of Java were in Webbrowsers, much of the focus of Java security has beenin providing features for protecting against hostileapplets; that is,against hostile code downloaded fromWeb sites on the Internet. Java security builds upon

350 KOVED ET AL.

three fundamental aspects ofthe Java run-time envi-ronment: the ByteCode Verifier, the Security Man-ager, and the ClassLoader.

The ByteCode Verifier ensures that downloadedcode is properly formatted, that bytecodes (Java Vir-tual Machine instructions) do not violate the safetyrestrictions of the language or virtual machine (noillegal data conversions), that pointer addressing isnot performed, that internal stacks cannot overflowor underflow, and that bytecode instructions willhavethe correct typed parameters. 2

The Security Manager initiates run-time access con-trols on attempts to perform file I/O and network I/O,create new ClassLoaders, manipulate threads orthread groups, start processes on the underlying plat-form (operating system), terminate the Java VirtualMachine (JVM), load non-Java libraries (native code)into the JVM, perform certain types of windowingsys-tem operations, and load certain types of classes intothe JVM. For example, the Java applet sandbox! se-verely constrains downloaded applets to a limitedset of functions that are considered to be relativelysafe.

The ClassLoader determines how and when appletscan load code and ensures that applets do not re-place system-level components within the run-timeenvironment.

In addition, a number of features in the Java pro-gramming language and run-time environment, in-cluding automatic memory management and strongdata type safety, facilitate writing safe code.

Through the use of digitalsignature servicesprovidedin JDK 1.1, trusted applets can be treated in a man-ner similar to applications written in Java. That is,these trusted applets have much greater access toJVM resources than applets that run in the restrictedJava sandbox. Improved and much more flexible ac-cess control features are the major security additionin JDK 1.2 and are described in greater detail laterin this paper.

Today's computing environments have a number ofsecurity weak points that are addressed by featuresavailable in Java prior to JDK 1.2:

• Strong memory protection-Java removes the pos-sibilityof either maliciouslyor inadvertently read-ingor corrupting memory locations outside bound-aries of the program. As a result, Java applications

IBM SYSTEMS JOURNAL, VOL 37, NO 3, 1998

Policy-based access toresources

Stack annotation basedwithbeginPrivileged() andendPrivileged( )

JavaCryptographicExtensions 1.2

Unconstrained accessgiven to applications

,";~ ::: :;:', '::', ",:,-,: ',',:<'f',: ::;,: :'::',Constrainec:;~~ss givento unsigned applets(Java sandboX)Signed appletsunconstrained

,\t,\":':ii;'"' ",~:~,','i,;~','::,' :

Notavailable

:<·,:;~'!:'i..':':... ,> ,:,JavaCryptographicExtensions 1.1

JavaCryptographicArchitecture DSAsignature

• Lexical scoping of privilege modification: enforces the"least privileged model"; that is, only the piece of codethat needs the privilege will be enabled.

• Cryptographic services for data confidentiality andintegrity: allows for the encryption and verification of data,

• Digital signature services for code signing: provides theability to have authentication of the origin of the code(e.g., who signed it)

The table below summarizesthe significant securityfunctionality found in the various major JDK releases.

(Java sandbox)

Notavailable

Notavailable

Unconstrained accessgiven to applications

Notavailable

Cryptographic servicesfordataconfidentialityand integrity

Digital signature servicesfor codesigning

The evolution of Java has also significantly changed theavailabilityof security function from releaseto release.Following is a summary of the major security functionsfound in three of the Java releases.

• Applet resource access: resource access given to codedownloaded from the Web (i.e., applets).

• Application resource access: resource access given tocode that is local to the system running the JVM (i.e., anapplication).

or applets cannot gain unauthorized memory ac-cess to read or change contents.

• Encryption and digital signatures-Java supportsthe use of powerful encryption technology to ver-ify that an applet came from an identifiable sourceand has not been modified.

• Rules enforcement-Java is completely object-based. By using Java objects and classes to rep-resent corporate information entities, it is possi-

ble to explicitly state the rules governing the useof such objects.

Java run-time environment. Java, as an object-ori-ented language, can be used to develop applicationsin much the same way as C and C+ + are used toimprove programmer productivity. In contrast tomany other programming languages, Java providesa standard set of libraries, including a broad range

IBM SYSTEMS JOURNAL, VOL 37, NO 3, 1998 KOVED ET AL. 351

The improvements needed in Java security are aimed atassuring that e-business applications are secure. Thefollowing schematic highlights the needed movement froman initial applet-only deployment scenario, with minimalprotection requirements, to an environment where anyprogram type (e.g., applet, servlet, etc.) has the sameprotection primitives and a policy enforcement mechanismcapable of uniform policy enforcement available on allplatforms. In addition, the functionality improvements andassurance quality from release to release will improve thestrength of protection provided.

of communications and security capabilities, thussimplifying construction and deployment of client/server and distributed systems applications. It alsoprovides data type safety and performs bytecode ver-ification when the code is loaded into the JVM run-time environment. This catches bugs that arise fromprogramming errors, especially with pointer arith-metic and array out-of-bounds indexing errors.

Additionally, Java-based support environments ex-ist for the following:

352 KOVED ET AL.

Note: The term "Secure Dynamically Bound Code"in the following schematic refers to a collecton ofdistributed applets assembled within a single HTMLpage or a collection of JavaBeans or EnterpriseJavaBeans composed in an application builder, ordynamically during run time, to construct anapplication.

• Applets-downloadable code with restricted ac-cess, usually coupled with a browser

• Aglets-code pushed to the end device rather thanthe pull model of applets

• Servlets-Java code on the server• Orblets-code utilizing object request broker com-

munication mechanisms

Any of these environments may utilize a componentmodel for reusability, such as Javalseansv"" and En-terprise JavaBeans**.5


Java is evolvingto support a multitude of system con-figurations:

• Embedded systems destined to be found in manyconsumer devices in the home and elsewhere

• Java-based smartcards• Personal management devices such as pagers and

PDAs (personal digital assistants)• Network computers-thin and flat clients• Mobile systems• Highly scalable enterprise servers

To support this range of configurations, a family ofproducts-including JavaOS, PersonalJava, Enter-prise Java, and JVMs hosted in application builderenvironments-is evolving to meet the unique needsfound in the respective environments.

Security requirements vary depending on the uniquecharacteristics of these substantially different envi-ronments. Initial work indicates that a common se-curity model is likely and that the environmental dif-ferences can be supported by providing extensions,rather than deploying significantly different securitymodels. The use of a common security model willsimplify and reduce the cost of application and li-brary development and deployment.

JDK 1.2 permissions model

The discussion below is based on beta-level code;some operational changes may result from industryfeedback prior to general availability.

JDK 1.2introduces a number of new security featuresthat make it easier to enforce access control of pro-tected resources." In earlier versions of Java, JVMresource access was enforced by the "sandbox" se-curity model. Extensions were usually limited to fea-tures implemented by the platform provider (e.g.,browser, Web server). The new JDK 1.2 permissionmodel is much more flexible and even permits ap-plication-defined resources to be added to the ac-cess control system. Java programs now have the abil-ity to define access restrictions on sensitive resourceswithout requiring the writing of a new Security Man-ager or modifying the underlying platform. Thismeans that applets downloaded into a browser, orservlets loaded into a Java server, can add resourceaccess controls to a JVM without having to modifythe underlying browser or server implementation.

One of the notable features of the new security modelis that most of the access control implementation is


contained in the Java security subsystem. Typically,Java programs (e.g., applets, servlets) and compo-nents or libraries (e.g., packages, beans) do not needto contain any access control code. When a programwants to add protected resources to the JVM, amethod call can be added that will check whetherthe restricted operation is permissible. One generaltechnique employed in JDK 1.2 is to create aguardedobject, whereby access to an object or operations onan object are restricted by an access control call. Ex-amples of how to use the access control features areshown later in this paper.

The JDK 1.2access control subsystem introduces newconcepts. The first is CodeSource, which is the com-bination of a set of signers (digital certificates) anda codebase URL (uniform resource locator). TheCodeSource is the basis for many permission and ac-cess control decisions. The second concept is the se-curity policy. The policy contains a number of grantentries that describe the permissions granted to aparticular CodeSource (see the "Policy Database"sidebar, later). A grant entry may contain one ormore Permissions, which is the right to access or usea protected resource or guarded object. Lastly, a Pro-tectionDomain is an aggregation of a CodeSource andthe Permissions granted for the CodeSource as spec-ified in the policy database. Each class file loadedinto the JVM via a ClassLoader is assigned to aProtectionDomain, as determined by the CodeSourceof the class.

Loading Java programs. The three legs of JVM se-curity are the ByteCode Verifier, the Security Man-ager, and the ClassLoader. Prior to JDK 1.2, eachapplication had to write its own subclasses ofSecurityManagerand ClassLoader. JDK 1.2 simplifiedthe development process by creating a subclass ofClassLoader called SecureClassLoader. SecurityMan-ager no longer is abstract and can be instantiated orsubclassed. Most of its methods now make calls tomethods in classAccessController, which provides theaccess control function in the JDK 1.2. Since most ofthe SecurityManager methods call AccessController,this greatly simplifies the writing of new SecurityMan-ager subclasses.

To automatically invoke the new security subsystem,a Java application is started from the command lineof a native operating system. The Java run time cre-ates an instance of SecureClassLoader, which in turnis used to locate and load the class file of the ap-plication. A subclass of SecurityManager is createdand installed in the Java run time. The main()method

KOVED ET AL. 353

of the application is then called with the commandline arguments.

The purpose of the change in the Java run time forstarting Java applications is twofold. First, a simpleSecurityManager is installed in the system that usesthe new Java security access control subsystem. Sec-ond, a SecureClassLoader is used to safely and cor-rectly load classes into the Java run time.

SecureClassLoader has several important purposes.The first is to make sure that searching for classesis done in the correct order. When the JVM needsa class, SecureClassLoader first looks for files refer-enced by the classpath of the JVM to see whether itis available. Files in the classpath are intended to bethe completely trusted classes that are part of theJava run time. For example, all ofthe code shippedwith the JVM is included in the classpath, and is there-fore considered trusted code. If not found in theclasspath, an application-defined location can besearched (e.g., a Web server via a URL request). Fi-nally, code maybe part of Java Standard Extensions,which is a set of classes that are available in the hostfile system but are not part of the JVM classpath.Classes in the Standard Extensions are typically lo-cated on the disk drive of the host system (e.g., theworkstation or personal computer), but the classesare not part of the fully trusted run-time classes ofthe JVM.

The second important purpose of SecureClassLoaderis to create and set the ProtectionDomain informa-tion for classes loaded into the JVM. When the Se-cureClassLoader loads a class into the JVM, thecodebase URL and the digital certificate used to signthe class file (if present) are used to create a Code-Source. The CodeSource is used to locate (or instan-tiate) the ProtectionDomain for the class. The Pro-tectionDomain contains the Permissions that havebeen granted to the class. Once the class file has beenloaded into the JVM, SecureClassLoader assigns theappropriate ProtectionDomain to the class. This Pro-tectionDomain information, and, in particular, thePermissions in the ProtectionDomain, is used in de-termining access control during run time.

Once a Java program starts to run, the SecureClass-Loader assists the JVM in loading other classes re-quired to run the program. These classes are alsoassigned the appropriate ProtectionDomainsbased ontheir CodeSource.

354 KOVED ET AL.

Run-time access controls. At various points duringthe execution of a Java program, access to protectedresources is requested. Such access includes, but isnot limited to, network I/O attempts, local file I/O,or attempts to create a new ClassLoader or to accessa program-defined resource. To verifywhether the run-ning program isallowed to perform the operation, thelibrary routine makes a call to the SecurityManager'scheckPermission(permissionToCheck) method, whichsubsequently calls AccessController.checkPermission(permissionToCheck). These method calls are respon-sible for determining whether the current thread hassufficient permissions. checkPermission() takes a Per-missionobject as an argument. The AccessControllermethod checkPermission() walks back through thestack frames of the current thread, obtaining the Pro-tectionDomainfor each of the classes on the thread'sstack (see the section on "Thread stack frames"). Aseach ProtectionDomain in the thread stack is located,the permissionToCheck is compared to the Permis-sions contained in ProtectionDomain. For each stackframe, if permissionToCheckmatches one of the Per-missions in the ProtectionDomain, testing of the Per-missions continues with the ProtectionDomain of thenext stack frame (class) on the stack. This testing re-peats until the end of the stack is reached. That is,all of the classes in the thread have permission toperform the operation. Thus, the access controlcheck succeeds, typicallymeaning that the requestedoperation is able to proceed. If permissionToCheckis not granted to all classes on the stack (there is noappropriate Permission in all of the ProtectionDo-mains of the classes), then a SecurityException isthrown, and access to the resource is denied.

A flaw in the above scenario is when a class has aset of Permissions and does not care who its callersmay be, as for example, a JavaBean installed on adesktop computer needing to read files from the lo-cal disk drive. The ProtectionDomain of the bean'sclass has a Permission to read these local files. How-ever, the program loaded from a Web server thatcalls the bean has a ProtectionDomain that does nothave local file read permission. Normally, ifthe beanwere called by the program loaded from the Webserver, the bean would be denied access to the fileson the local disk drive because the program fromthe Web server does not have a local file read Per-mission.However, if the bean calls AccessController.beginPrivileged(), an annotation is made on the stackframe of the thread, indicating that when Ac-cessController.checkPermission{permissionToCheck)searches for ProtectionDomains, the search stops atthis stack frame. The bean may make any number


of method calls,but when AccessController.checkPer-mission(anotherPermissionToCheck) is called, thesearch back through the stack frames to find Pro-tectionDomains stops at this stack frame. Based onthe above scenario, the ProtectionDomains for thebean will be checked, but the ProtectionDomainsforthe program from the Web server are not checkedsince the search stopped at the stack frame for thebean. Therefore, the file read operation willsucceed.To turn off this privileged mode of operation, a callto AccessController.endPrivileged() removes the stackannotation. If the application were to forget to callAccessController.endPrivileged(), the JVM gracefullyrecovers because the beginPrivileged() and endPrivi-leged()call are associated with the stack frames. Thatis, once the method that called beginPrivileged(} ex-its, the privileged mode is automatically turned off.

A subtle aspect of the above beginPrivileged( }/endPriv-ileged() operations is that programs creating newthreads would lose ProtectionDomain informationwhen a new thread is created. That is, each newthread creates a new run-time stack. The classes onthe stack of the parent thread are not present in thenew thread. Important ProtectionDomain informationis no longer available when a checkPermission() op-eration is performed. This would give new threadsmore permissions than the threads that created them.To get around this apparent loss of security infor-mation, the ProtectionDomainsof the parent threadare attached to (inherited by) a child thread whenit is created. So, unless a beginPrivileged() operationis performed in the child thread, the ProtectionDo-mains of the parent thread are also checked duringa checkPermission(} operation.

To gain an appreciation of these capabilities, a few examples are given.

Example 1: Applets from www.NominallyWidgets.com. signed by adigital certificate called LarrysCertificate can read files in directory/tmp and write files in directory /tmp/koved on the local disk drive.Note the wild card """8$ the 1m character otthe first quoted argument.Many permissions supPOrt the wild card as the last character of thefirst argument.

-Code base URL-indicating where theclasses are residing. If omitted, the codecan be from any source.

_Digital certificate used to sign theclasses/JAR file. If omitted,AccessController will not check whetherthe code is signed or not.

- The fUlly qualified name of the permissionclass (includes the package name),e.g., java.utiI.PropertyPermission. }

-The first quoted argument for the '---'-~••••permission constructor, e.g., "java.version".

-The second quoted argument is an optionalmodifier, e.g., "read".

-The last argument is an optional name thathas been assigned to a digital certificate forthe permission class; e.g., the permissionclass (see the first bullet above) was loadedover the network and was signed with adigital certificate.

The CodeSource is also comprised of two parts:

The Permissions consist of one or more entries,each of which is comprised of four parts:

The default JDK 1.2 access control subsystemimplementation uses a policy database(e.g., a flat file) to describe access controlpolicies. Each grant entry contains two parts:a CodeSource and a list of Permissions.

IBM SYSTEMS JOURNAL, VOL 37, NO 3, 1998 KOVED ET AL. 355

Thread stack frames

Each thread in the JVM contains a number of stack"frames." Simply stated, these frames contain themethod instance variables for each method calledin the current thread. If a program debugger wereused, the debugger would be able to show the in-stance variables for each of the methods on the stack.For further clarification, a couple of examples areoffered.

Example 1: Simple check of the current thread. Fig-ure 1 shows a snapshot of a program, called MyPro-gram, with a codebase URL of http://www.Nominal-lyWidgets.com.After the security subsystem has beeninitialized, the program tries to get a system prop-erty by calling System.getProperty("java.home"). ThegetProperty method calls the Security Managermethod, checkProperty(), to see whether the currentthread is allowed to read a system property. In turn,the Security Manager calls the method AccessCon-troller.checkPermissionwith an argument of Proper-tyPermission("java.home", "read") to see whether allof the classes on the stack have the appropriate per-missions.

Note that as of the writing of this paper, classesloaded via the JVM classpath are not assigned to aProtectionDomain. These classes logicallyare assignedto the system domain, which has unrestricted accessto all Java and application-defined resources. Thatis,when the AccessControllerdoes its checking, it as-sumes system domain classes have all permissions.

The access control in this example works as follows:

• Class java.security.AccessController is in the systemdomain. Bydefault, the system domain has implicitpermission to read the properties; checking is al-lowed to proceed to the next stack frame.

• The class java.lang.SecurityManager is in the sys-tem domain. By default, the system domain hasimplicit permission to read the properties; check-ing is allowed to proceed to the next stack frame.

• Class java.lang.System is in the system domain. Bydefault, the system domain has implicit permissionto read the properties; checking is allowed to pro-ceed to the next stack frame.

• MyProgram has a ProtectionDomain with a code-base of http://www.NominallyWidgets.com. Thepermissions for this ProtectionDomain are checked.If the permission is not granted, a security excep-tion would be thrown, and the getProperty() methodcall would fail. If the permission is granted, check-

356 KOVED ET AL

ing is allowed to proceed to the next stack frame.In this example, the permission is granted, sochecking is allowed to proceed to the next stackframe.

• MyProgram has a ProtectionDomain with a code-base of http://www.NominallyWidgets.com. Thepermissions for this ProtectionDomain are checked.The permission is granted; checking is allowed toproceed to the next stack frame.

• The class java.langThread is in the system domain.Since system domain has the implicit permissionto read the properties, checking is allowed to pro-ceed to the next stack frame.

In this example, the operation is permitted since thechecks succeeded for all stack frames.

If this thread had been created by another threadwith ProtectionDomainsin any of its stack frames, theinherited ProtectionDomainsfrom the parent threadwould also be checked.

Obviously, there is room for optimization becausemany of the ProtectionDomainson the thread's stackare not unique. In practice the Permissions in eachunique ProtectionDomain are checked only once percall to checkPermission().

Example 2: beginPrivileged( ) was called. In this ex-ample, a thread was created, and a program calls abean (MyBean) containing a protected resource. My-Bean callsAccessController.beginPrivileged() and thencalls a method in MyBeanProtected that will checkto see whether the thread has the appropriate per-missions.

The thread's stack is presented in Figure 2.

The access control works as follows:

• java.lang.SecurityManageris part ofthe system do-main, so it has implicit permission to access theresource. Proceed to the next stack frame.

• MyBeanProtected is part of the ProtectionDomainthat has access to the resource. Proceed to the nextstack frame.

• MyBean is part of the ProtectionDomain that hasaccess to the resource. Since AccessController.be-ginPrivileged() was called from this stack frame, stophere; do not check any more stack frames.

The following two-stage algorithm describes how Ac-cessControiler computes permissions.

IBM SYSTEMS JOURNAL. VOL 37. NO 3. 1998

Figure 1 Simple check of the current thread Figure 2 beginPrivileged( ) was called

SOmePackage.NewThread.run

j8va.Iang.$ecurityManager.checkPermission

java.lang.Thread.run

java.securily.AccessController.checkPermIssi<Itl

MyBeanProtected.accesslVIyBean-initMyProgram.parseArgumenls

javaJang.System.getProperty

MyProgram.main

java.lang.SecurityManager.checkProperty

java.lang.Thread.run

java.securily.AccessController.checkPermission

Figure 3 AccessController algorithm stage one

Foreachclasson thestack,Gettheclass'sProtectionDomaln,If thestackframehasbeenmarkedwitha beglnPrivileged annotli\tion,

exitthe loop.If the laststackframecheckedwasnot markedwithbeginPriVlleged,

add the ProtectionDomains Inherited by the currentThread\¥i1en thecurrentThreadwascreated.

Figure 4 AccessController algorithm stage two

If no ProtectionDomains fromstep 1, return(onlytullytrustedcodeIIIrunning).

CallP's implies() method:

Else,continue.

Doesthe Permission foundIn the previous step approveof the permission beingchecked?

If no, throwanexception.

Findthe appropriate PermissionCalfeetion associated withthe permission beingchecked.Findtheappropriate Permission InthePermissionCollection foundin thisstep.

ForeachuniqueProtectionDomain P obtained in step 1,

IBM SYSTEMS JOURNAL. VOL 37, NO 3, 1998 KOVED ET AL. 357

Figure 5 JDK 1.2 Permissions model relationships

copy ProtectionDomainreferences to the arrays

issueimplies(permission)onthePermissionCoileetion

find relevant Permissionobject(s) in thecollection

get PermissionColiection'!"----+! associated with

permission beingchecked'sclass

AccessControIContext.checkPermission( )

AccessControIContext.checkPerrnission( )


NO


jvm.cgetlnheritedAccessControlContext( )

,----..:...-'._.L.-...:...-'. ..:...-'._---'-,.

358 KOVED ET AL. IBM SYSTEMS JOURNAL. VOL 37, NO 3. 1998

Figure 6 JDK 1.2 Permissions model relationships (continued)

The first step is to obtain a list of ProtectionDomainsused by the second step as shown in Figure 3.

The second step is to check with each of the Pro-tectionDomains to see whether it contains the per-mission being checked (Figure 4).

If an exception is not thrown, the requested oper-ation is permitted.

The flowcharts in Figure 5 and Figure 6 graphicallyindicate how the new functions just described relate.

Tools

There are three important security tools and two datarepositories in JDK 1.2.These tools are primarily ori-ented for users of the JDK rather than for end usersof applications that incorporate Java. They are de-scribed below.

The Java archive (JAR) utility tool (here representedas jar) was designed mainly to facilitate the pack-aging of Java object files and resources into a single


file, or archive. When Java components (class, im-age, audio, etc.) are placed in an archive, they canbe downloaded via a single HTIP (HyperText Trans-fer Protocol) transaction with a server rather thanrequiring a separate HTIP connection for each down-loaded component. Network download performanceis generally improved, especially since the jar toolcan compress the contents of the archive.

Cryptographic key management, keytool, is a cryp-tographic key and certificate management utility. It,along with jarsigner (see below), replaces the JDK1.1 javakey tool. The keytool utility allows develop-ers to administer their own public or private cryp-tographic key pairs and associated certificates for usein client authentication, or for data integrity and au-thentication services, requiring digital signatures.This utility also allows the caching of the public keyof a communicating peer (e.g., a Web server).

Keytool manages a keystore (repository) of privatekeys and the associated X.509 certificate chains au-thenticating the corresponding public keys.The key-store may be protected with a passphrase (as in the

KOVED ET AL. 359

default implementation from JavaSoft) or by a stron-ger protection mechanism (e.g., cryptography). Thereare two basic entries in the keystore:

• Key or certificate entries-consist of a private keyand a certificate chain

• Trusted certificate entries-multiple single certif-icates with public key entries

Keytool can create a keystore, clone or delete en-tries in a keystore, import certificates (trusted andnontrusted), export certificates, display the contentsofthe keystore, and generate self-signed certificates(including public or private key pairs).

Both Java 1.1 and 1.2 implementations of keytoolonly support the DSA (Digital Signature Algorithm)key and the DSNSHA-J (Secure Hash Algorithm) sig-nature algorithms. The key size is limited to a max-imum of 1024 bits.

For backwards compatibility, it is expected thatJDK 1.2 will be able to parse or process the JDK 1.1keystore format.

The utility for signing JAR files digitally,jarsigner, hastwo major functions: sign jar files, and verify the sig-nature(s) and integrity of signed jar files.

The certificate(s) contained in ajar file are used byjarsigner to verify the digital signature(s) and to ver-ifywhether or not the public key of the certificate(s)is contained within the specified keystore. Also, jar-signer verifies that the jar file has not been tamperedwith in anyway. Currently jarsigner can only sign jarfiles that were created with the jar utility.

Jarsigner can sign jar files using either the DSA keyalgorithm, with the SHA-l digest algorithm (the de-fault cryptographic engine provider supplies theDSNSHA-l algorithms) or the RSA** (derived fromthe original founders: Rivest, Shamir, and Adleman)key algorithm with the MD5 (modification detection)digest algorithm. That is, if the signer's public andprivate keys are DSA, jarsigner uses the DSNSHA-lalgorithms. If RSA keys are provided, the RSNMD5algorithms are used.

A jar file may be signed more than once by simplyrunning jarsigner more than once, specifying a dif-ferent signer each time.

Access control policy database management is han-dled bypolicytool, a graphical user interface that as-

360 KOVED ET AL.

sists a user, such as a system administrator, in spec-ifying, generating, editing, exporting, or importinga security access control policy for the JVM. The toolcreates a policyfile as described below.

As described above, the keystore, cryptographic keystorage, is a repository of private keys and the as-sociated X.509 certificate chains authenticating thecorresponding public keys.The keystore is a concreteimplementation of the keystore class provided in thejava.security package. All three utility programs de-scribed above use the keystore.

The policy for a Java run time, specifying which per-missions are available for code from various codesources, is represented by a Policy (access controlpolicy database) object. More specifically, it is rep-resented bya Policysubclass providing an implemen-tation of the abstract methods in the Policy class(which is defined in the java.security package). A de-fault implementation of Policy, called PolicyFile,reads the policy information from flat ASCII files.Thepolicy framework allows policy information to bestored on the local system or anywhere in the net-work.

The policy configuration file(s) for Java 1.2 instal-lation specify what permissions (which types of sys-tem resource accesses) are allowed by code fromspecified code sources. The information stored in thepolicy database is described in the "Policy Database"sidebar.

Java and browser-based security models

Browsers and other Internet technologies were inthe marketplace prior to the broad introduction ofJava; consequently, it is not surprising that mis-matches exist in the security models provided by therapidly evolving Java related technologies. Majorprogress toward synchronization can occur if agree-ment can be reached on selected parts of the mod-els in an orderly fashion. The mismatches result pri-marily from the early limitations of Java security andthe desire to fill these voids to meet customer re-quirements. One such area where there is a con-certed effort in model alignment is in the access con-trol model.

This section provides a high-level view of the capa-bility classes of a representative browser with com-parable features found in the Java 1.2 security ar-chitecture. Both use a stack-based approach toauthorization. However, they employ significantly


different access control models and authorizationmechanisms. The browser's proposal is more ambi-tious, but the added functionality may be more dif-ficult to manage.

It should be recognized that mismatches also existamong browser security models as they expand sup-port to cover the hosting of HyperText Markup Lan-guage (HTML) pages, scripts, and applets. In someenvironments, signed Java applets will have reducedaccess to some Java elements because the contain-ing page or script calling the applet is not signed.Only the Java access control mechanisms of thebrowser will be highlighted in the following discus-sion.

Alternative access control model. A commerciallyavailable Web browser's Java Virtual Machine im-plementation that uses an alternative access controlmodel based on targets and explicit activation or de-activation of permissions was examined. 7,8 A targetis a mapping of a principal to an operation on anobject (i.e., roughly a traditional permission repre-sentation). Whether a permission can be enabled ornot depends on a three-valued logic for "enabling"policy. Essentially, if at least one principal (user, sys-tems administrator, target class definer) permits thetarget and no principal forbids the target, the targetcan be enabled. Java developers can enable such tar-gets at run time. Also, developers can disable (for-bid) or revert (undo enabling of) targets at run time.This model enables the policy of multiple principalsto be combined and less than maximal rights to begranted to an applet. It is up to the applet code tomanage this subset of enabled permissions.

At run time, targets are activated by enablePrivilege(),prohibited by disablePrivilege(), and deactivated byrevertPrivilege(). Reverting only affects the callingstack frame, so targets enabled in previous stackframes are still active and supersede the reversion.Therefore, it is not possible for a descendant methodto remove a privilege, possibly enabling security ex-posures.

The browser authorization mechanism checks thestack for an enabled privilege for the request. Ifoneis found, the operation is permitted regardless of thetrust of the classes in the thread's stack (the meth-od's callers). Therefore, explicit prohibition orproper permission reversion of rights is necessary toprevent an unauthorized principal from using anoth-er's "enabled" privilege.Note that there may be other


methods that enabled the permission higher in thethread stack.

If a method in the Java core classes (the basic Javarun time) requires the addition of access controls toclose a security hole, the browser model describedin this section will cause trouble for existing code.It is straightforward to add a permission to allow thecode to enable the permission. However, the code

The browser model providesmore functionality than

the Java model.

does not already contain code to enable the permis-sion since the permission was not required when thecode was originally written. The same would be truefor library and bean writers who discover in subse-quent versions of their software that they need toadd access controls. The implication is that appli-cation writers would have to update their code tosupport (i.e., enable) any new permissions added tothe base Java classes or libraries and beans they em-ploy. This results in severe version managementproblems. This problem does not exist with the JDK1.2 access control model. In JDK 1.2, only an updateto the policy database is required.

In summary, the browser model provides more func-tionality than the Java model, but this functionalityplaces more responsibility on programmers to trackgranted and retracted rights and to be aware ofbrowser, JVM, or library/bean version differences.

Stack-based authorization

The current access control mechanisms in Java arebased on "stack introspection," or logically walkingthe stack frames of the thread to see whether thecalling methods or classes have sufficientpermissionsto perform a requested operation. Given the coarsegranularity of the current permission structure, theperformance of stack-based authorization appearsto be acceptable. However, since all security issuescannot be reduced to stack introspection, it is pos-sible for one object to pass rights to another objectand obtain information that it could not otherwisedirectly obtain. For example, it may be possible to

KOVED ET AL. 361

induce another object to pass a right (e.g., a file de-scriptor) to an unauthorized object. The unautho-rized object was not on the stack when the file de-scriptor was created, yet it still received the objectreference ("off-the-stack" spoofing). This style of se-curity attack is inherent to stack-based authorizationtechniques because the technique does not track allunsafe interactions between objects.

In environments such as those with stringent com-munication requirements (e.g., requiring hierarchi-cal, lattice-like, communication protocols regardinginformation flow) the Java security model may notbe adequate. However, for most of the envisioneduses of Java, stack introspection-based access con-trol features are adequate for implementing mission-critical applications.

Security requirements-a high-level view

The following requirements address needs identifiedbeyond the level of function currently planned to bedelivered in JDK 1.2; discussions are underway withJavaSoft on many of them, and some may be ad-dressed by the time of JDK 1.2 or in follow-on JDKreleases. These are representative categories and ex-amples of requirements within each category, notnecessarily a complete compilation of known re-quirements within each category.

• Java Virtual Machine high-integrity computing envi-ronment: The requirement is to support concur-rent applet or servlet execution with multiple setsof security credentials. Because authentication andcredentials requirements vary between systems,and sometimes between subsystems, it is necessaryfor the applets or servlets within a JVM to supporthandling multiple sets of security credentials. Sim-plified APIs (application programming interfaces)will make it easier for application writers to ex-ploit these security features.

Satisfaction of this requirement should enable se-cure interactions between clients and servers andbetween server subsystems as is needed for e-corn-merce applications.

• Policy-driven Java security model and security ser-vices: Customers should be able to define and de-ploy a security policy. The underlying systems (e.g.,Java) should have sufficient mechanisms to imple-ment and enforce that policy. Mechanisms for en-forcing policy need to include support for: accesscontrol, cryptographic and quality of protection,

362 KOVED ET AL

trust, secure delivery of policy statements to theJVM, policy administration, and JVM support of apolicy engine.

Satisfaction of this requirement may reduce thetotal cost of ownership through simpler configura-tion and policy administration by making the JVMa single point of policy enforcement for all Javaapplications.

• Simple security programming models: Require sim-ple high-level APIs for quality of protection (pri-vacy, integrity, and nonrepudiation) to allow se-curity-unaware applications to obtain defaultsecurity protection for such functions as securecommunications, secure documents or mail, securestreams, and secure remote method invocation(RMI) and Internet Inter-Orb Protocol (nor)."

This requirement may simplify the programmingmodel, making security permissions readily avail-able to any application and reducing potential mis-takes made by security-naive programmers.

• Standards for secure deployment ofapplications: Amanifest format and single signature standards(such as W3C) for applet and application deliveryare needed.

This requirement should establish a single and low-cost way of ensuring the delivery of applicationsboth to the server and client systems.

• Standardized programming models: Create stan-dards for establishing trust and integrity of appli-cations consisting of multiple applets embeddedin HTML or XML (Extensible Markup Language)documents.

This requirement may provide a single model forthe allocation of access control or other policy toan application that may consist of a number ofcomponentized elements.

• Native security services support: Utilize the securityfeatures of the underlying platform.

This requirement should maximize platform secur-ity functionality, improve performance, and allowfor consistency.

• Standards for development and deployment of (cryp-tographic) service providers: Cryptographic service


providers should be signed and provide enumer-ated descriptions of the services within the pro-vider.

This requirement should ensure that internationaldeployment requirements are met and needed in-formation is accessible to applications requiringthese services. Cryptographic services can be de-ployed internationally with control of the strengthof cryptographic operations (e.g., key length, sig-nature length, algorithm strengths, etc.).

• Maintainability, scalability,and interoperability: Pro-vide centralized administration and the ability toreact to changes, the ability to interoperate andutilize non-Java security capabilities, and the abil-ity to support full security functionality in a dis-tributed manner as needed between clients andservers.

This requirement should allow for the controlleddeployment of Java and improves performance andmigration.

• Removal of security as an impediment to perfor-mance: Allow hardware-supported or native-sup-ported implementations of algorithms to be usedduring validation of class files, and allow policy todefine where a combination of trusted signer andusage of a trusted compiler will permit the over-ride of dynamic bytecode verification at class loadtime.

Many security functions are highly performance-intensive (e.g., hashing, key generation); improve-ments are needed to approach performance foundin non-Java environments.

It should be noted that Java does not run in isola-tion; it runs in the context of the operating systemplatform on top of which it has been implemented.In addition, Java is frequently embedded inside an-other application, such as a Web browser or Webserver. Each of these operating systems and sub-systems has an impact on the JVM and Java run-timevulnerability to security attacks. 10-13 When deploy-ing Java programs, care should be taken in config-uring the JVM and application files to minimize vul-nerability to security attacks; this discussion isoutsidethe scope of this paper.


Future directions

With continued strong support from the software in-dustry, many enhancements required to bring theJava environment in line with the most stringentneeds generally provided in the non-Java environ-ment today are possible. These features includestrong encryption, sophisticated access control, andthe ability to provide centralized security policy man-agement. Some of these capabilities are likely to be-come available beginning in mid-1998 and through-out 1999. Much work is also underway to provideJava extensions for accessing existing industrial-strength security mechanisms, thus improving sys-tem integrity, performance, and functionality. In thefuture, we will also see high-level e-commerce andother types of applications migrate from individu-ally provided security capabilities to utilize the ca-pabilities in the latest release of the JDK. Bylate 1998or early 1999, significant initial security functional-ity should be expected in all Java environments.

IBM, Lotus, and Tivoli are working vigorously withthe Java software industry to bring the business-crit-ical enterprise security requirements forward and en-sure that they are met. IBM's Java initiative is acutelyaware of the need to focus on securing the Java envi-ronment.

Acknowledgments

The authors would like to thank Li Gong, the Javasecurity architect at Sun Microsystems, for in-depthreviews of JDK 1.2 security, as well as reviewing thispaper. We would also like to thank the followingpeo-ple from IBM who are actively involved in improvingthe Java security environment and to whom muchinsight and original thinking influenced ideas in thispaper: Bob Blakley III, Trent Jaeger, Paul Karger,Peter Thull, and anonymous reviewers.

Thanks also to JavaSoft's security group for devel-opment insights for JDK 1.2 and for the ongoing re-lationship between IBM/Lotus and JavaSoft in evolv-ing the Java functionality to meet enterprise classsecurity needs.

*Trademark or registered trademark of International BusinessMachines Corporation.

**Trademark orregistered trademark ofSun Microsystems, Inc.or RSA Data Security, Inc.

KOVED ET AL. 363

Cited references

1. M. Zboray, Java-Good Start, but Not Yet Secure, GartnerGroup, Information Security Strategies (ISS) (December1996).

2. T. Lindholm and F. Yellin, The Java Virtual Machine Spec-ification, Addison-Wesley Publishing Co., Reading, MA(1997).

3. D. Flanagan, Java in a Nutshell: A Desktop Quick Reference,O'Reilly & Associates, Sebastopol, CA (1997).

4. "JavaBeans (1.0)," http.z/www.javasoft.com, Sun Microsys-terns (1996).

5. V. Matena and M. Hapner, "Java Enterprise Beans (0.79),"http://www.javasoft.com. Sun Microsystems (1997).

6. S. Oaks,Java Security, O'Reilly & Associates, Sebastopol, CA(1998).

7. J. Roskind, "Evolving the Security Model for Java from Nav-igator 2.x to Navigator 3.x: setScopePermission," http://developer.netscape.comllibrary/documentation/security/sectnI.html (1997).

8. J. Roskind, "Security Tech Note #2: Activating Codebase Prin-cipals," http://developer.netscape.comllibrary/documentation/security/sectn2.html (1997).

9. The Common Object Request Broker: Architecture and Spec-ification, Version 2.2, Chapter 13, OMG, Object ManagementGroup (February 1998).

10. J. S. Rothfuss and J. W. Parrett, "Go Ahead, Visit Those WebSites, You Can't Get Hurt ... Can You?," 20th National In-formation Systems SecurityConference, sponsored by NIST andthe National Computer Security Center, Baltimore, MD (Oc-tober 7-10, 1997), pp. 80-94.

11. E. W. Felten, D. Balfanz, D. Dean, and D. S. Wallach, "WebSpoofing: An Internet Con Game," 20th National Informa-tion Systems Security Conference, sponsored by NIST and theNational Computer Security Center, Baltimore, MD (Octo-ber 7-10, 1997), pp. 95-103.

12. W. Cooke, "Stupid JavaScript Security Tricks," 20th NationalInformation Systems Security Conference, sponsored by NISTand the National Computer Security Center, Baltimore, MD(October 7-10, 1997), pp. 116-127.

13. R. Kemmerer, F. De Paoli, and A. L. Dos Santos, "Vulner-ability of 'Secure' Web Browsers," 20th National InformationSystems Security Conference, sponsored by NIST and the Na-tional Computer Security Center, Baltimore, MD (October7-10, 1997), pp. 488-497.

Accepted for publication March 20, 1998.

Larry Koved IBM Research Division, T.1. Watson Research Cen-ter, Po. Box 218, Yorktown Heights, New York 10598 (electronicmail: [email protected]).Mr. Kovedjoined the Research Cen-ter in 1982 and has worked in a number of areas that involve net-work computing. He has built multiuser collaborative systems,including multiuser virtual reality systems incorporating visual-izations of numerical simulations. He has also worked on a num-ber of mobile computing projects, including user interfaces formobile computing and algorithms for data replication. His cur-rent work is in component-based software, including security is-sues that arise with the deployment of mobile, or downloadable,software.

Anthony J. Nadalin IBM Network Computing Software Division,/l400 Burnet Road, Austin, Texas 78758 (electronic mail:[email protected]). Mr. Nadalinjoined the former IBM Fed-

364 KOVED ET AL.

eral Systems Division in 1983,where he worked on secure projectsfor the government. In 1987 he began working on secure oper-ating systems design. The work included evaluations of MVS™and VM (virtual machine) operating systems, in support of IBMdevelopment laboratories, with the goal of producing commer-cial "off-the-shelf' secure operating systems. In 1992 he trans-ferred to the Application Systems/400 Division to complete anevaluation of secure operating systems and databases. While onspecial assignment to the Personal Software Products (PSP) Di-vision, he worked on the specification and prototype Object Se-curity Services (aSS). In 1995 Mr. Nadalin joined the PSP di-vision where he was part of the security design team for baseoperating system and distributed computing. He assisted in thetransfer ofthe ass prototype to the SOMobjects™ group for usein Component Broker. In 1996 he joined the Internet Divisionand continued to work on distributed object security.

Don Neal IBM Network Computing Software Division, 4205 S. Mi-ami Boulevard, Research TrianglePark, North Carolina 27709 (elec-tronic mail: [email protected]).Mr. Neal, a Senior TechnicalStaff Member, joined IBM in 1973, and has worked on a numberof technical assignments in the areas of the telecommunicationsenvironment, networking architecture and network design, high-speed communications, multivendor interoperability, and systemsmanagement. He joined the lIT Security Programs area in 1997with responsibilities for security strategy and architecture, witha particular focus on Java security.

Tim Lawson Lotus Development Corporation, I Rogers Street,Cambridge, Massachusetts 02142. Mr. Lawson joined Lotus in 1984and has worked on the testing and development of Lotus 1-2-3®,Symphony'", SmartSuite®,and other business applications for theworldwide market. He is currently the development manager forthe eSuite™ Infrastructure-a Java-based abstraction layer forthe eSuite Devpack applets. The eSuite Infrastructure providesplatform- and browser-independent persistence services and theuser interface for the applets. Immediately prior to this, Mr. Law-son worked as architect for eSuite security technologies in col-laboration with IBM and JavaSoft.

Reprint Order Number G321-5681.


Documents

The evolution of Java security - IBM · The evolution of Java security by L. Koved A. J. Nadalin D. Neal T. Lawson This paperprovides a high-leveloverview ofthe development andevolution