sasiOakland

8/14/2019 sasiOakland

1/10

IRM Enforcement of Java Stack Inspection

Ulfar ErlingssondeCODE Genetics

Lynghals 1, 110Reykjavk, Iceland

[email protected]

Fred B. SchneiderDepartment of Computer Science

Cornell UniversityIthaca, New York 14853

[email protected]

Abstract

Two implementations are given for Javas stack-inspection access-control policy. Each implementation isobtained by generating an inlined reference monitor (IRM) for a different formulation of the policy. Performance of theimplementations is evaluated, and one is found to be competitive with Javas less-exible, JVM-resident implementa-tion. The exercise illustrates the power of the IRM approach for enforcing security policies.

1. Introduction

Java was designed to support construction of applica-tions that import and execute untrusted code from acrossa network. The language and run-time system enforce se-

curity guarantees for downloading a Java applet from onehost and executing it safely on another. In Suns Java im-plementation [12, 14, 11], some of these security guar-antees involve run-time checks by the JVM (Java VirtualMachine), others involve load-time checks on the JVML(Java Virtual Machine Language) bytecode les deningJVM classes the unit of JVM binary code and of Java object hierarchiesand still others follow from the syntax of JVML and the Java programming language.

The JVM run-time checks enforce access-control poli-cies that associate access rights with the class that initi-ates the access. The sandbox policy of early (pre Java 2)JVM implementations distinguishes between code residinglocally and code obtained from across the network. The

Supported in part by ARPA/RADC grant F30602-96-1-0317, AFOSRgrant F49620-94-1-0198, Defense Advanced Research Projects Agency(DARPA) and Air Force Research Laboratory, Air Force Material Com-mand, USAF, under agreement number F30602-99-1-0533, National Sci-ence Foundation Grant 9703470, and a grant from Intel Corporation. Theviews and conclusions contained herein are those of the authors and shouldnot be interpreted as necessarily representing the ofcial policies or en-dorsements, either expressed or implied, of these organizations or the U.S.Government.

more recent Java 2 stack inspection policy renes this. InJava 2, whether an access is permitted can depend on thecurrent nesting of method invocations. Enforcement of thestack inspection access-controlpolicy therefore relies on in-formation found on the JVM run-time call stack.

Changing which access-control policy is supported bythe JVM requires changing the JVM. Thus, programs ex-pecting Java 2s stack inspection policy to be enforced can-not execute on earlier-generation JVM implementations.On a JVM that enforces the stack inspection policy, ap-plications requiring other access-control policies might beruled out altogether, might require awkward constructions 1,or might be forced to employ their own application-levelcustom enforcement mechanisms. Finally, such a JVM in-cludes mechanisms that may or may not be needed for ex-ecuting any given Java application. For embedded applica-tions, where memory is at a premium, the size of the JVM

footprint is crucial; there is considerable incentive to omitunused enforcement mechanisms.This paper describes an alternative to putting access-

control enforcement in a run-time environment, such as theJVM. We show how an in-lined reference monitor (IRM)can be merged into Java applications to enforce securitypolicies like stack inspection. With the IRM approach, atrusted rewriter instruments applications with checks thatcannot be circumventedand that cause execution to be mon-itored for violations of a specied security policy. 2 TwoIRM implementations of stack inspection are reportedone is a reformulation of security passing style proposedin [19, 20]; the other is new and exhibits performance that

is competitive with existing commercial JVM-resident im-plementations.

1 For example, certain access-control policies can be implemented withstack inspection only by creating multiple copies of the same class in dif-ferent code bases or by creating multiple instances of identical class load-ers.

2 The IRM approach is capable of enforcing EM policies [16], an ex-tremely rich class that includes mandatory and discretionary access con-trol, Chinese Wall, type enforcement, and the Clark-Wilson commercialpolicy but that excludes certain information ow policies.


2/10

Figure 1. IRM approach to security policy enforcement.

Java 2s stack inspection policy is a particularlychalleng-ing one to enforce with an IRM because state relevant topolicy enforcement (the JVM run-time call stack) is not di-rectly accessible to Java applications. That we are able toobtain a new implementation exhibiting competitive perfor-mance reects well on the practicality of the IRM approach.And having an IRM implementation for stack inspection

means that Java 2 programs can be run on earlier genera-tion JVM implementations, that variants of stack inspectionas well as entirely new security policies can be enforced onJava programs without changing the JVM, and that unusedenforcement mechanisms need not bloat Java applicationsor the JVM.

We proceed as follows. Section 2 briey summa-rizes our PoET/PSLang toolkit for synthesizing IRMs;PoET/PSLang is a successor to our SASI tool [7]. Section 3reviews Java 2s stack inspection policy and the primitivesthat implement this policy. An IRM version of the security-passing style [19, 20] implementation of stack inspection isdescribed in Section 4; an IRM implementation for a new

way to support Java 2s stack inspection policy is given inSection 5. Finally, Section 6 concludes with some remarksabout the IRM approach and about limitations we discov-ered in Javas stack inspection policy.

2. Inlined Reference Monitors

For a reference monitor [2] to enforce a security policy,(i) it must mediate all events relevant to the policy being en-forced, (ii) its integrity must be protected from subversionby applications, and (iii) its presence must be transparentto applications [15]. Address-space isolation has tradition-

ally been employed for ensuring the integrity of referencemonitors, but other approaches are also feasible.

With an in-lined reference monitor, a load-time, trustedrewriter merges checking code into the application itself and uses program analysis and program rewriting to protectthe integrity of those checks. The application is thus trans-formed by the rewriter into a secured application , whichis guaranteed not to take steps violating the security policybeing enforced. See Figure 1.

Specifying an IRM involves dening

security events , the policy-relevant operations thatmust be mediated by the reference monitor;

security state , information stored about earlier securityevents that is used to determine which security eventscan be allowed to proceed; and

security updates , program fragments that are executedin response to security events and that update the secu-rity state, signal security violations, and/or take otherremedial action (e.g. block execution).

Policy Enforcement Toolkit (PoET) [6] implementsIRMs for JVML applications. A primary concern in thedesign of PoET was the trusted computing base. PoETcomprises approximately 17,500 lines of Java source codeand thus increases the size of the trusted computing baseby that amount. Although the PoET rewriter does localoptimizations on inserted codeto delete (some) superu-ous enforcement checksit does not attempt global pro-gram analysis because we feared further increases to thesize and complexity of the trusted computing base. In ad-dition, PoET works at the level of JVML (and not the Javaprogramming language). 3 Transforming Java programs in-stead of JVML programs would make a Java compiler partof the trusted computing base, an unwise choice given thesize and complexity of Java compilers. Moreover, by choos-ing to transform JVML programs, we do not require thatsource code for an application be available at a site for a se-curity policy to be imposed by the site on that application.

Note that the PoET rewriter need not be run on the samecomputer as the JVM or even as the Java compiler. Thus,PoET contributes to the size of the trusted computing basewithout increasing the size of the run-time environmentused to execute Java applications. In most cases, PoET willrun on the same computer as the JVM, yet it is not dif-cult to imagine mobile-code and other networked settings

3 Currently, PoET does not process Java native methodscode writtenin native machine languageand this restricts what policies can be en-forced by excluding some security events. However, this is not a limitationof the IRM approach in general, as demonstrated by x86 SASI [7], whichimplements IRMs on x86 machine-language applications.


3/10

IMPORT LIBRARY Lock;ADD SECURITY STATE \{

int openWindows = 0;Object lock = Lock.create();

\}ON EVENT begin methodWHEN Event.fullMethodNameIs("void java.awt.Window.show()")PERFORM SECURITY UPDATE \{

Lock.acquire(lock);if( openWindows = 10 ) \{

HALT[ "Too many open GUI windows" ];\}openWindows = openWindows + 1;Lock.release(lock);

\}ON EVENT begin methodWHEN Event.fullMethodNameIs("void java.awt.Window.dispose()")PERFORM SECURITY UPDATE \{

Lock.acquire(lock);

openWindows = openWindows - 1;Lock.release(lock);\}

Figure 2. PSLang security policy that allows at most 10 open windows.

where security policies are added to an application beforethat application is distributed to other sites for execution.

The integrityof a PoET-inserted IRMs security state andsecurity updates is protected by JVML type-safety guaran-tees, since the JVML type system prohibits access to codeand data not in the classes originally comprising an appli-cation. JVML type-safety also means that JVML applica-tions are unaffected by the presence of checking code thatPoET adds to create an IRM. This is because JVML type-safety prevents code from being viewed as data, so code in-serted by the PoET rewriter cannot be directly detected bythe application that was modied. In addition, JVML type-safety prevents a Java application from mentioning namesand types not in that applications original namespace; thePoET rewriter chooses the names and types for any check-ing code it adds accordingly. 4

Security policies for PoET are specied using PolicySpecication Language (PSLang), an event-oriented, im-perative language with Java-inspired syntax. PSLang is a

small subset of Java so that the PSLang compiler could besmall. In PSLang security policies, any JVM event thatcould occur during execution of the original applicationfrom method calls to arithmetic operationscan be identi-ed as a security event and, therefore, will trigger execu-

4The presence of an IRM for certain policies cannot be completely hid-den. Reection and the measurement of execution timing can allow a Javaapplication to detect added code (but does not compromise security en-forcement).

tion of an associated security update. PSLang is expressiveenough to specify the EM policies of [16]. 5

To illustrate the syntax of PSLang, Figure 2 gives a pol-icy to prevent Java applications from opening more than10 Java windows. The security state is dened in the ADDSECURITY STATE block at the start of the specication.It consists of an integer variable ( openWindows ) and amutual exclusion lock ( lock ). Variable openWindowscounts the number of open windows; lock is used to pro-tect openWindows from concurrent access. Security up-dates are introduced by PERFORM SECURITY UPDATE(two are in Figure 2), and security events are identied byON EVENT ... WHEN tags. The two security events inthe policy of Figure2 specify that the IRM executessecurityupdates prior to method invocations for opening and closingJava windows. Whenever the application attempts to opena window, the JVM executing the application is terminated(because HALT is invoked) if 10 windows have already beenopened (i.e., openWindows = 10 ); otherwise, openWin-dows is incremented. And whenever a window is closed,openWindows is decremented.

5 To be precise, any security policy that can be specied using a secu-rity automaton involving transition predicates that are JVM events can beformulated in PSLang.


4/10


5/10

Method call/return: A BAt start of B , look up protection domain P B for B scode and push P B on the thread-local domain-Stack . At return from B (either normally or bya thrown exception), pop domainStack , remov-ing P B .

doPrivileged {S }Push a distinguished token doPriv on domain-Stack , at the beginning of the doPrivileged ,and pop the token off at the end (whether an ex-ception was thrown or not).

checkPermission (P )Scan domainStack from top to bottom (withoutmodifying it), and look at each protection domain p. Throw a security exception if p does not implyP , but accept if p = doPriv or the bottom of do-mainStack is reached.

Create thread: T Set the domainStack of T to contain a copy of the contents of the domainStack of its parentthread.

Table 1. IRM SP S implements security-passing style.

loading a le that contains bit maps for the font. We thenhave:

In invoking load(thesis.txt) , thecheckPermission will throw a security excep-tion if protection domains File System (the frame atthe top of the stack) and Untrusted Applet (the nextand bottom frame on the stack) do not each imply theneeded permissions for reading that le. They do if thesis.txt resides in /home/ue .

In invoking load(Courier) while executingin use plain font , the checkPermission willthrow a security exception if protection domains FileSystem (the frame at the top of the stack) and GUILibrary (the next frame on the stack) do not each im-

ply the needed permissions for reading that le. Theydo if Courier resides in /fonts . Untrusted Ap-plet is not checked for permissions, because the invo-cation of load in GUI Library is within the scope of a doPrivileged .

Javas stack inspection policy also handles dynamic cre-ation of threads. When a new thread T is created, T is givena copy of the existing run-time call stack to extend. Thesuccess of subsequently evaluating checkPermission inthread T thus involves permissions associated with the callstack (or some other representation of the permissions im-plied by the call stack) when T is created.

4. A Security-Passing Style IRM

The rst work on modifying JVML programs to enforcestack inspection is described in [19, 20]. There, an addi-tional variable is introduced to replicate information fromthe JVM run-time call stack. This variable is changed uponinvoking or returning from a method call as well as uponentering or exiting the scope of a doPrivileged block; the

variable is scanned when checkPermission is evaluated.The resulting scheme is called security-passing style (SPS)because the new variable is passed to method invocations as

an additional argument.SPS is an example of the IRM approach, so it will

be no surprise that we were able to use PoET and buildIRMSP S , an implementation of SPS. The security updatesthat IRM SP S associates with each security eventmethodcall and return, checkPermission , doPrivileged , andthread creationare sketched in Table 1; the actual PSLangformulation requires less than three pages and appears asAppendix A of [8].

In the PSLang that species IRM SP S , variable do-mainStack replicates policy-relevant information fromthe JVM run-time call stack; this variable is local to each

thread (and is equivalent to the additional explicit argumentto method invocations employed in [19, 20]). It is worthnoting exactly how IRM SP S handles security updates as-sociated with a method call from A to B . Permissions forB could be added to security state domainStack eitherinside method A or inside method B . But performing theupdate inside method A turns out to be less desirable in partbecause when B is a virtual method (the Java equivalent of a function pointer), a dynamic lookup would be requiredto determine its permissions. Therefore, IRM SP S does thesecurity update inside method B .

Performance Overhead

In order to understand the performance of stack inspec-tion implementations, we must know the frequency andcost of relevant security events in actual applications. Wetherefore measured four applications: the Jigsaw 2.01 webserver [3], Suns javac Java 1.1 compiler [12], the tarutility [5], and an MPEG video player [1]. All were run


6/10

Methodcalls

doPrivilegedcheckPermission

count avg checkedNew

threadsJigsaw 2,476,731 1,002 5,333 18.7 71javac 1,456,970 0 1,067 12.4 0tar 19,580 0 6,509 8.6 0MPEG 35.997.662 101 205 5.7 201

(a) Frequency of stack inspection primitives.

Method call doPrivileged checkPermission New thread1.00s 1.66s 7.7s 6.5s

(b) Benchmarked cost of IRM SP S primitives (at stack depth 10).

JVM IRM SP SJigsaw 6.2% 20.1%javac 2.9% 46.2%tar 10.1% 3.0%MPEG 0.9% 72.5%

(c) Overhead of JVM-resident and IRMSP S implementations.

Table 2. Assessing stack inspection performance.

using modern JVMs 7 with garbage collection disabled on a300Mhz Pentium II running Windows 98. Since quantify-ing access-control overhead was of interest, the rst threebenchmark applications used the same set of 500 small syn-thetic Java source les as their input.

Table 2(a) shows how many times the various stack in-spection primitives were invoked in the benchmarked appli-cations. The cost of doPrivileged , checkPermission ,and thread creation can be relative to the size of the JVMcall stack, andbecause checkPermission is dominantwe also report the average number of accessed stack frames(avg checked) for that operation. So that the numbersare less dependent on irrelevant implementation details,stack inspection primitives used in the construction of per-mission objects have not been counted. For instance, notcounted are the doPrivileged invocations for creatingeach java.io.FilePermission object in Suns im-plementation.

Table 2(b) shows the overhead, in microseconds, for theIRM SP S stack inspection primitives. The values shown areaverages from a synthetic benchmark of the primitives. Theprimitives in the last three columns were benchmarked us-ing a stack depth of 10each operation accessed 10 stack frames.

Table 2(c) compares the run-time overhead of Suns

7For JDK 1.1.7, we used Symantec Java! JustInTime Compiler Version3.10.107(i); for JDK 1.2, we used Suns distribution that employs Syman-tec Java! JustInTime Compiler Version 3.00.078(x).

JVM-resident implementation of stack inspection andIRMSP S . The column labeled JVM gives the percent-age overhead between running the application on Java 2sJVM with stack inspection enabled versus without stack in-spection enabled; the column labeled IRM SP S gives thepercentage overhead between running the application withIRMSP S on Java 1.1 8 versus without any IRM.

The measurements in Table 2 do not include the cost of constructing permission objects or of executing their im-plies methods. This better quanties the relative differ-ences in overhead between stack inspection implementa-tions. The numbers shown are based on the average exe-cution time for 15 runs of the synthetic benchmarks and theapplications. Percentages in Table 2(c) relate two of theseaverages. For each average we computed, the standard de-viation was found to be small enough to be ignored in inter-preting the numbers.

The JVM-resident implementation is considerablycheaper for Jigsaw, javac , and MPEG. This is not sur-prising because of the per method call cost of IRM

SP Sand the large number of method calls each of these appli-cations makes. However, when an application has manypermission checks relative to the number of method calls,IRMSP S may exhibit less overhead than the JVM-residentimplementation. This is because IRM SP S can amortize

8 We employed Java 1.1s JVM to measure the overhead of IRM SP Sbecause the stack inspection implementation already present in Java 2sJVM would otherwise distort the measurements.


7/10

Method call/return: A BNothing.

doPrivileged {S }At the beginning of the doPrivileged push thecurrent JVM call stack frame number onto privS-tack ; at the end pop it off (whether an exceptionwas thrown or not).

checkPermission (P )Let bottom be the privileged stack frame numberon top of privStack , or 0 if there is none. Scanthe current JVM call stack from top to bottom andnd the protection domain p for each stack framereject if ever p does not imply P . If there was noprivileged stack frame, likewise scan the ances-tralStack .

Create thread: T Let the ancestralStack of T be either a copyof the ancestralStack of its parent thread,with the current JVM call stack pushed on top,orif theres a privileged stack frame number onprivStack the top portion of the current JVMcall stack up to that privileged frame.

Table 3. IRM Lazy uses the JVM call stack.

the cost of creating domainStack over a large number of checkPermission s and each checkPermission is likely

to be as cheap, or cheaper, under IRM SP S . The results fortar illustrate this benet.

An Improved SPS Implementation Scheme

The overhead of an SPS stack inspection implementa-tion would be improved if the security state (i.e., domain-Stack ) were not updated on each method call. In fact,updates need to be made only when a method call crossesprotection domainsmethod calls within the same protec-tion domain repeatedly push the same permission onto do-mainStack , and checkPermission is unaffected by re-placing sequences of identical stack frames with a singleframe.

The implementation of [19, 20] exploits this insight.The implementation comprises 12,800 lines of Java code,of which 1700 lines implement an analysis to determinewhether invoked methods are in the same or different pro-tection domains as the invoker and 6900 lines are producedby JOIE, the generic JVML rewriter [4]. With these op-timizations, [19, 20] reports overall security enforcementoverheads of between 13% and 17% of total executiontimestill relatively high when compared to the overheadson the same applications run under the JVM-resident im-plementation stack inspection. Adding this optimization toIRM

SP Sdid not seem worthwhile, given the performance

gains we achieve in other ways with the IRM implementa-tion of the next section.

5. A New IRM Stack Inspection Implementa-tion

Suns implementation of stack inspection prots fromhaving direct access to the JVM call stack, because no over-

head is then incurred at method calls in order to keep track of nested invocations for subsequent checkPermission

evaluation. Since method calls are the common case, theperformance advantages of this design should be obvious.

In order to specify such a scheme in PSLang, some facil-ity is needed for accessing the JVM run-time call stack. For-tunately, such can be found in Java. First, Java provides aninterface so that exceptionscan print a textual description of the JVM call stack when they are thrown; second, the JavaSecurityManager contains a protected method get-ClassContext that returns a copy of the JVM call stack as an array of Class objects, each a unique identier forthe code at that JVM call stack frame. The PoET runtimemakes this latter interface accessible to PSLang specica-tions (as part of PoETs System library) by extending theSecurityManager .

Table 3 sketches security events and updates forIRMLazy , an IRM stack inspection implementation thatuses the JVM call stack. (The actual ve page PSLangformulation appears as Appendix B of [8].) Notice howwork has been moved from method call/return to the imple-mentation of doPrivileged , checkPermission , and newthread creation (which all must make a copy of the call stack when they are invoked). doPrivileged pushes the framenumber for the stack frame at the top of the current JVMcall stack onto a separate thread-local variable, privS-tack . This frame number then serves to bound the seg-

ment of the JVM call stack that must be traversed in eval-uating checkPermission stack frames appearing loweron that call stack are not checked. For each thread, the rel-evant stack frames of parent threads are stored in thread-local variable ancestralStack , since this informationcannot be derived from the current JVM call stack and it isneeded in evaluating any checkPermission that does notterminate early by reaching a doPrivileged frame.

Table 4(a) shows the cost of the stack inspection primi-


8/10

Method call doPrivileged checkPermission New thread0s 23.4s 22.4s 29.8s

(a) Benchmarked cost of IRM Lazy primitives (at stack depth 10).

JVM IRMSP S IRM LazyJigsaw 6.2% 20.1% 6.4%javac 2.9% 46.2% 2.0%tar 10.1% 3.0% 5.4%MPEG 0.9% 72.5% 0.4%

(b) Overhead of JVM-resident, IRMSP S , and IRM Lazy implementations.

Table 4. Assessing the IRMLazy stack inspection implementation.

tives with IRMLazy . As with Table 2(b), reported measure-ments are averages from a synthetic benchmark that repeat-edly performed the subject operation.

Notice that, except for method calls, the measured costsfor each stack inspection primitive in Table 4(a) are higherthan the IRM SP S costs given in Table 2(b). These highercosts arise because the entire stack is now being copied bythe implementations of all but the method call/return stack inspection primitives. Even so, for our benchmark applica-tions, IRMLazy exhibits overall performance that is supe-rior to IRM SP S and that is competitive with Suns JVM-resident implementation. This is seen in Table 4(b), and itis a consequenceof method call/return invocations dominat-ing performance of our benchmarks. Where IRMLazy per-formsbetter than the JVM-resident implementation, it is be-cause of optimizations in our PSLang specication, whichdo a better job of eliminating redundant work in permissionchecking. 9

6. Concluding Remarks

The idea of separating mechanism from the policy thatdirects this mechanism is advocated often. Java 2s sup-port for the stack inspection access-control policy involvesa mechanism (in the JVM) and the exibility to direct thatmechanism through policy les, protection domains, andpermission classes (with their implies methods). OurIRM realizations of stack inspection actually draw a some-

what different line between policy and mechanism. Withno JVM-resident mechanism, there is considerable exibil-ity about what policies can be enforced using the IRM ap-proach and about when that choice of policy must be made.

This exibility allows enforcement of policies that al-ter or extend what the JVM implements today. One mightnow contemplate remedying the various deciencies in theJava 2 stack inspection access-control policy, allowing

9Similar optimizations are done in IRM SP S .

changing protection domains, permissions, and theimplies method after execution of an application iscommenced, enabling straightforward creation of new

protection domains as execution proceeds;

thecoupling between protection domains and bytecodeorigin to be rened so that, for example, an applica-tions state is used in determining the protection do-main for code; and

the operation of doPrivileged to be extended so thatonly a subset of the privileges in a protection domainare amplied in a block of code.

It now even becomes possible to enforce different secu-rity policies on different Java applications, raising ques-

tions about detecting and resolving incompatibilities be-tween those policies. However, these questions about policycomposition are independent of whether or not the IRM ap-proach is being used to enforce policies.

The IRM approach is exible because it allows securityevents and security updates to be associated with any ap-plication event. This degree of exibility can be only ap-proximated by wrapping security enforcement code aroundan interface, as done by Naccio [9] (for method calls)and Generic Software Wrappers [10] (for system calls).Software-based fault isolation (SFI) [18] enforces a mem-ory protection policy by object-code editing, and recentwork on distributed virtual machines also is concerned with

enforcing security policies by code rewriting [17]. Clearly,the set of enforceable security policies is restricted if, as inthis related work, only somenot allpotential securityevents can be monitored, only some security state main-tained, and only some types of security updates supported.

Flexibility is a double-edged sword. The IRM approachis not only exible enough to implement Java 2s stack in-spection (in multiple ways!) and to implement a host of vari-ants that address apparent limitations in the policy, but it is


9/10

also exible enough to allow policies to be dened that haveunanticipated consequences or vulnerabilities. We have noway to guarantee that our PSLang formulations of stack in-spection are indeed the policy supported by Suns distribu-tion. To get such assurance, we would need a formal spec-ication of Suns stack inspection implementation and we

would need a logic for PSLang specications. Neither ex-ists. But PSLang could easily be givena formal semantics interms of security automata, and then it would not be difcultto reason about and/or simulate PSLang policies in order togain condence that they describe what is intended.

Even without a logic for reasoning about PSLang spec-ications, the exercise of formulating stack inspection inPSLang, a formal language, did prove enlightening. Writ-ing the PSLang security updates forced us to ask questionsabout what really happens when security events occur. Sur-prising things about the semantics of stack inspection cameto light:

If a new thread is created from within adoPrivileged block then that thread will continueto enjoy amplied privilegeseven though its codemight not be within the scope of a doPrivilegedblock and even after its creator has exited from withinthe doPrivileged . This is because the new threadstarts execution with a copy of its creators call-stack (whose top frame is marked as being within the scopeof a doPrivileged ).

When a class B extends some class A but does notoverride As implementation of a method foo () , thenthe protection domain for A (and not B ) will alwaysbe used by checkPermission for foo s stack frame.Because B can extend A in ways that may affectthe se-mantics of foo , (such as by overriding other methods),one might argue that the wrong protection domain isbeing consulted. 10

Both of these features of stack inspection will becomeapparent to attentive readers of the PSLang formulationsthat appear in the appendices of [8]. This is not to say thatthere arent also surprises in our PSLang formulations orthere arent aspects of the Java 2 behavior that we missed inconstructing these formulations. But havingin just a fewpagesa complete and rigorous description of the policybeing enforced seems like a necessary condition for under-

standing that policy.

Acknowledgments

Discussions with Li Gong have been helpful as thiswork has evolved. We also thank Andrew Myers, AndrewBernard, Michal Cierniak, Robert Grimm, and the programcommittee for comments on earlier drafts of this paper.

10 The rationale for the choice that was made is given in [11, 3.11.3].

References

[1] Anders, J. Java MPEG Player. Fakult at fur Infor-matik, Technische Universit at Chemnitz, Chemnitz,Germany, http://rnvs.informatik.tu-chemnitz.de/ .

[2] Anderson, J.P. Computer security technology plan-ning study. Technical Report ESD-TR-73-51, U.S. AirForce Electronic Systems Division, Deputy for Com-mand and Management Systems, HQ Electronic Sys-tems Division (AFSC), Bedford, Massachusetts, Oc-tober 1972, volume 2, 5869.

[3] Baird-Smith, A. Jigsaw: An Object OrientedServer. W3C Note, World Wide Web Con-sortium, MIT Laboratory for Computer Sci-ence, Cambridge, Massachusetts, June 1996,http://www.w3.org/Jigsaw/ .

[4] Cohen, G., J. Chase, and D. Kaminsky. Automaticprogram transformation with JOIE. Proceedings of 1998 Usenix Annual Technical Symposium , (New Or-leans, Louisiana, June 1998), 167178.

[5] Endres, T. Java Tar Package. ICE En-gineering, Inc. , Lake Linden, Michigan,http://www.ice.com/java/tar/ .

[6] Erlingsson, U. The Inlined Reference Monitor Ap- proach to Security Policy Enforcement , Ph.D. thesis,Cornell University, Ithaca, New York, 2000.

[7] Erlingsson,U. and F.B. Schneider. SASI Enforcementof Security Policies: A Retrospective. Proceedings

1999 New Security Paradigms Workshop (CaledonHills, Canada, September 1999), ACM Press, NewYork.

[8] Erlingsson, U. and F.B. Schneider. IRM Enforcementof Java Stack Inspection. Technical Report TR2000-1786, Computer Science Department, Cornell Univer-sity, Ithaca, New York, February 2000, http://cs-tr.cs.cornell.edu:80/Dienst/UI/1.0/Display/ncstrl.cornell/TR2000-1786 .

[9] Evans, D. and A. Twyman. Policy-directed codesafety. Proceedings IEEE Symposium on Security and Privacy (Oakland, California, May 1999), IEEE Com-puter Society, California, 3245.

[10] Fraser, T., L. Badger, M. Feldman. Hardening COTSSoftware with Generic Software Wrappers. Proceed-ings IEEE Symposium on Security and Privacy (Oak-land, California, May 1999), IEEE Computer Society,California, 216.


10/10

[11] Gong, L. Inside Java 2 Platform Security: Archi-tecture, API Design, and Implementation , Addison-Wesley, Menlo Park, California, 1999.

[12] Gosling, J., B. Joy, and G. Steele. The Java LanguageSpecication , Addison-Wesley, Menlo Park, Califor-nia, 1996.

[13] Liang, S. and G. Bracha. Dynamic Class Loadingin the Java Virtual Machine. Proceedings of 1998 ACM Conference on Object-Oriented Programming,Systems, Languages and Applications (Vancouver,Canada, October 1998), SIGPLAN Notices 33(10),3644.

[14] Lindholm, T. and F. Yellin. The Java Virtual MachineSpecication , 2nd edition. Addison-Wesley, MenloPark, California, 1999.

[15] Saltzer J.H. and M.D. Schroeder. The Protection of In-

formation in Computer Systems. Proceedings of the IEEE 63 , 9 (Sept. 1975), 12781308.

[16] Schneider, F.B. Enforceable Security Policies. ACM Transactions on Information and System Security 2 , 4(February 2000). To appear.

[17] Sirer, E.G., R. Grimm, A.J. Gregory, B.N. Bershad.Design and Implementation of a Distributed VirtualMachine for Networked Computers. Proceedings of the 17th ACM Symposium on Operating Systems Prin-ciples (Kiawah Island, SC, Dec. 1999), ACM, 202216.

[18] Wahbe, R., S. Lucco, T.E. Anderson, and S.L. Gra-ham. Efcient Software-Based Fault Isolation. Oper-ating System Review , 27(5), ACM Press, 1993.

[19] Wallach, D.S. A New Approach to Mobile Code Se-curity , Ph.D. thesis, Princeton University, New Jersey,January 1999.

[20] Wallach, D.S. and E.W. Felten. Understanding JavaStack Inspection. Proceedings 1998 IEEE Symposiumon Security and Privacy (Oakland, California, May1998), IEEE Computer Society, California, 5263.

Documents

sasiOakland