F. Yellin. "Low level security in Java." In Fourth International World Wide Web Conference, Boston, MA, Dec. 1995. Available via http://www.w3.org/pub/Conferences/WWW4/Papers/ 197/40.html .  Home/Search   Document Not in Database   Summary   Related Articles   Check

....imposed by the Java security model. Every time the Java Virtual Machine [97] JVM) runs a piece of code a class file in Java s terminology the following steps occur [55] 1. The Java virtual machine obtains a class file and accepts it if the file passes preliminary bytecode verification [185]. 2. The Java virtual machine determines the class s code source. This step includes signature verification, if the code appears to be signed. 3. The Java virtual machine consults the security policy and composes the set of permissions to grant to this class. In this step, the policy object will ....

F. Yellin. Low level security in Java. Fourth International World Wide Web Conference (Boston, Massachusetts, USA, December 11--14,

.... and 2 above by performing ill typed operations at run time, such as forging object references from integers, illegal casting of an object reference from one class to another, calling directly private methods of the API, jumping in the middle of an API method, or jumping to data as if it were code [19, 58, 33]. Thus, bytecode verification is a crucial security component in the Java sandbox model: any bug in the verifier causing an ill typed applet to be accepted can potentially enable a security attack. At the same time, bytecode verification is a complex process involving elaborate program ....

....the virtual machine, and access control checks in the API. The purpose of bytecode verification is to shift the verifications listed above from run time to loading time. 3. Basic verification by dataflow analysis The first JVM bytecode verification algorithm is due to Gosling and Yellin at Sun [19, 58, 33]. Almost all existing bytecode verifiers implement this algorithm. It can be summarized as a dataflow analysis applied to a type level abstract interpretation of the virtual machine. Some advanced aspects of the algorithm that go beyond standard dataflow analysis are described in sections 4 and 5. ....

Yellin, F.: 1995, `Low level security in Java'. In: Proceedings of the Fourth International World Wide Web Conference. pp. 369--379.

....the GC and updated; for example, when moving a stack, the frame pointers must be adjusted. 2.6 Verifier and Translator The verifier is an important part of JX. All code is verified before it is translated to native code and executed. The verifier first performs a standard bytecode verification [48]. It then verifies an upper limit for the execution times of the interrupt handlers and the scheduler methods (Sec. 2.8) 2] The translator is responsible for translating bytecode to machine code, which in our current system is x86 code. Machine code can either be allocated in the domain s fixed ....

F. Yellin. Low level security in Java. In Proc. of the 4th World Wide Web Conference, pp. 369-379, OReilly,1995.'

....4.3 Security Considerations A high level of security is crucial for the acceptance of a platform for Grid computing. At first glance, Java runtime systems seem to offer comprehensive security features that meet the requirements of an execution environment for Grid computing: lan guage safety [24], classloader namespaces and access control based on dynamic stack introspection. Despite these advantages, current Java runtime systems are not able to protect the host from faulty (i.e. malicious or simply bugged) applications. In the following we point out serious deficiencies of Java that may ....

F. Yellin. Low level security in Java. In Fourth International Conference on the WorldWide Web, MIT, Boston, USA, December 1995.

.... and 2 above by performing ill typed operations at run time, such as forging object references from integers, illegal casting of an object reference from one class to another, calling directly private methods of the API, jumping in the middle of an API method, or jumping to data as if it were code [9, 31, 14]. The Java Card architecture features components 1 and 2 of the sandbox model: applets are executed by the Java Card virtual machine [29] and the Java Card runtime environment [28] provides the required access control, in particular through its firewall . However, component 3 (the bytecode ....

....Section 5 gives preliminary performance results. Related work is discussed in section 6, followed by concluding remarks in section 7. 2 TRADITIONAL BYTECODE VERIFICATION In this section, we review the traditional bytecode verification algorithm developed at Sun by Gosling and Yellin [9, 31, 14]. Bytecode verification is performed on the code of each non abstract method in each class of the applet. It consists in an abstract execution of the code of the method, performed at the level of types instead of values as in normal execution. The verifier maintains a stack of types and an array ....

[Article contains additional citation context not shown here]

Yellin F. Low level security in Java. In Proc. 4th International World Wide Web Conference, pages 369--379. O'Reilly, 1995. 22

....code. 22] Its Write Once Run Anywhere capability is a result of the Java Virtual Machine which sits in between the native operating system and Java applications as show in Figure 7. The Java source code is compiled into an intermediate byte code which is run inside the Java interpreter. [22, 34, 9] Since Java applications are interpreted, the program can be executed in a secure runtime environment. Both the safeness of the language design and the system architecture help ensure the safeness of Java applications. 44 3.2.1 Language The safety of the Java language stems from its goal to ....

....accessed through objects. There are no pointers (but references) no global variables, and no notion of memory records or structures . Since there are no pointers, there can be no pointer arithmetic or pointer de referencing, forcing programs to access only those objects they create themselves. [23, 34] Arrays in Java are true arrays in that they are bound and limited to their size. A program that tries to access data outside of the array s range faces a run time error. Strings also have similar high level support in Java. Another safety measure is to prevent uninitialized objects from being ....

[Article contains additional citation context not shown here]

F. Yellin, Low Level Security in Java, WWW4 Conference, JavaSoft, December, 1995. http://www.javasoft.com:/sfaq/verifier.html. 114

....programming language that is well suited for building distributed applications where users can download code that they can locally execute. To combat the security risks associated with mobile code, Sun has developed a security model for Java and a central role is played by bytecode veri cation [7, 18], which ensures that no malicious code is executed by a Java Virtual Machine (JVM) Bytecode veri cation takes place when loading a Java class le and the process veri es that the loaded bytecode program has certain properties that the interpreter s security builds upon. By checking these ....

F. Yellin. Low level security in Java. In World Wide Web Journal: The Fourth International WWW Conference Proceedings, pages 369-380, Cambridge, MA, 1995. O'Reilly.

.... bytecode veri cation to ensure that programs are well formed, strong typing to guarantee that values are used according to their de nition, automatic memory management to prevent errors such as deleting a live object, and memory protection to prevent array and stack operations from over owing [12]. While safety is not the same thing as security it is an essential foundation for the latter [13] 2.2. Information ow control Over the last 20 years an abundant body of work has been devoted to information ow control. Multilevel security policies [14] originally conceived for military ....

....provide a more lightweight alternative to PCC. In type theoretic solutions the security properties that can be speci ed over components are determined by the information provided by the type system. Essential properties include language safety [13] as enforced by the byte code veri er in Java [12] or by Typed Assembly Language [29, 30] 2.5. Summary While information ow policies are too restrictive, neither discretionary access control nor certi ed code directly provides a solution. Access control mechanisms dependent on dynamic checks are error prone since it is easy to forget one ....

Yellin F. Low level security in Java. Fourth International Conference on the World-Wide Web, 1995.

....programming language that is well suited for building distributed applications where users can download code that they can locally execute. To combat the security risks associated with mobile code, Sun has developed a security model for Java and a central role is played by bytecode verification [7, 18], which ensures that no malicious code is executed by a Java Virtual Machine (JVM) Bytecode verification takes place when loading a Java class file and the process verifies that the loaded bytecode program has certain properties that the interpreter s security builds upon. By checking these ....

F. Yellin. Low level security in Java. In World Wide Web Journal: The Fourth International WWW Conference Proceedings, pages 369--380, Cambridge, MA, 1995. O'Reilly.

....code generable by current compilers and which enables future compilers to make more extensive use of subroutines. 1 Overview Java [AGH00, GJSB00] is normally compiled to a platform independent bytecode language, which is executed by the Java Virtual Machine (JVM) LY99] For security reasons [Yel95, Gon99] the JVM veri es incoming code prior to executing it, i.e. it checks certain type safety properties. Since compilers check equivalent properties on Java source, code produced via compilation must pass veri cation. The main cause of complexity for bytecode veri cation is subroutines. Subroutines ....

Frank Yellin. Low level security in Java. In Proc. 4th International World Wide Web Conference, pages 369-379. O'Reilly & Associates, December 1995. Also available at http://java.sun.com/sfaq/verier.html.

.... and 2 above by performing ill typed operations at run time, such as forging object references from integers, illegal casting of an object reference from one class to another, calling directly private methods of the API, jumping in the middle of an API method, or jumping to data as if it were code [8, 24, 10]. The Java Card architecture features components 1 and 2 of the sandbox model: applets are executed by the Java Card virtual machine [22] and the Java Card runtime environment [21] provides the required access control, in particular through its rewall . However, component 3 (the bytecode veri ....

....veri cation. Section 5 gives preliminary performance results. Related work is discussed in section 6, followed by concluding remarks in section 7. 2 Traditional Bytecode Veri cation In this section, we review the traditional bytecode veri cation algorithm developed at Sun by Gosling and Yellin [8, 24, 10]. Bytecode veri cation is performed on the code of each non abstract method in each class of the applet. It consists in an abstract execution of the code of the method, performed at the level of types instead of values as in normal execution. The veri er maintains a stack of types and an array ....

[Article contains additional citation context not shown here]

F. Yellin. Low level security in Java. In Proc. 4th World Wide Web Conference, pages 369-379. O'Reilly, 1995.

.... and 2 above by performing ill typed operations at run time, such as forging object references from integers, illegal casting of an object reference from one class to another, calling directly private methods of the API, jumping in the middle of an API method, or jumping to data as if it were code [9, 36, 15]. Thus, bytecode veri cation is a crucial security component in the Java sandbox model: any bug in the veri er causing an ill typed applet to be accepted can potentially enable a security attack. At the same time, bytecode veri cation is a complex process involving elaborate program analyses. ....

....once and for all, by static analysis of the bytecode at loadingtime. Bytecode that passes veri cation can then be executed at full speed, without extra dynamic checks. 3 Basic veri cation by data ow analysis The rst JVM bytecode veri cation algorithm is due to Gosling and Yellin at Sun [9, 36, 15]. Almost all existing bytecode veri ers implement this algorithm. It can be summarized as a data ow analysis applied to a type level abstract interpretation of the virtual machine. Some advanced aspects of the algorithm that go beyond standard data ow analysis are described in sections 4 and 5. In ....

F. Yellin. Low level security in Java. In Proceedings of the Fourth International World Wide Web Conference, pages 369-379. O'Reilly, 1995.

....other agent in the system. 6 4.1 Requirements Language safety in Java already guarantees some basic protection, as it is not possible to forge object references. In Java safety depends on strong typing, memory protection (overflow checks) automatic memory management, and byte code verification [24]. However, language safety itself does not guarantee protection in a mobile agent execution environment. Pervasive aliasing in object oriented languages leads to a situation where it is impossible to determine which objects belong to a certain agent and therefore to check whether an access to a ....

F. Yellin. Low level security in Java. In Fourth International Conference on the World-Wide Web, MIT, Boston, December 1995.

....of pointers and pointer arithmetic in the programming language itself helps to prevent coding mistakes and provide basic security. The Java compiler also prevents illegal cast operations. Furthermore, the interpreter checks every class before execution to ensure that the code plays by the rules [Yel96]. The object oriented standard libraries provide good abstractions to write platform independent code. Especially the AWT framework and the abstraction of basic TCP IP communication mechanisms, are very suitable. The language itself is very simple and clean. Telescript is a very interesting ....

....same size and contains the same type of objects, methods are called with appropriate arguments, fields are modified with values of the appropriate type. Pass four does some postponed tests of pass three. For more detailed information about the byte code verifier and low level security in Java see [Yel96]. B.7.3 The Class Loader Class loaders of a stand alone application can help to implement security policies. Class loaders can be used to ensure that a unique name space for classes from different sources (e.g. different network hosts) exists. Classes loaded from the local file system (often ....

F. Yellin. Low Level Security in Java. WWW, Sun Microsystems, 1996.

....not load the source code of an agent but already compiled code in the form of class files there is no way of determining whether the bytecodes were produced by a trustworthy compiler or by an adversary attempting to exploit the agency. Therefore a class verifier is called for. The class verifier [6][7] of Java is used to check every class that is loaded into the Java virtual machine over the network. Before any loaded code is executed, the class is scanned and verified to ensure that it conforms to the specification of the Java virtual machine. The class verifier operates in four passes. ....

F. Yellin, "Low Level Security in Java", 1997, deleted from www.javasoft.com.

....or it could have been created by a C program compiled with a special compiler for the virtual machine. 3 This situation means that the ClassLoader must verify that the bytecode does not violate the safety that Java guarantees. Aside from simple format checks, the bytecode verifier checks: 5][7] ffl that it doesn t forge pointers ffl that it doesn t violate access restrictions ffl that it accesses objects as what they are ffl that it calls methods with appropriate arguments of the appropriate type ffl that there are no stack overflows Along with checking the validity of the ....

Frank Yellin, Low Level Security in Java. Available via http://www.w3.org/pub/Conferences/WWW4/Papers/197/40.html 14

....provided by the computing environment. In short, the goal of memory protection is to avoid the malfunctioning of one execution unit from contaminating other execution units or even the host itself. Memory protection also goes by other names in the mobile code literature, namely, low level security [126] or simply safety [59] In traditional operating systems, memory protection is achieved by three mechanisms in combination: 2 In fact, competent operating systems offer other kinds of protection mechanisms, including CPU protection, instruction protection, I O protection, etc. In a mobile code ....

Frank Yellin. Low level security in Java. In World-Wide Web Conference, Boston, MA., December 1995. Also available at http://www.javasoft.com/ sfaq/ verifier.html.

No context found.

F. Yellin. "Low level security in Java." In Fourth International World Wide Web Conference, Boston, MA, Dec. 1995. Available via http://www.w3.org/pub/Conferences/WWW4/Papers/ 197/40.html .

No context found.

F. Yellin. Low level security in java. In 4th International World Wide Web Conference Proceedings, pages 369--379. O'Reilly, 1995.

No context found.

F. Yellin. Low Level Security in Java, 1995.

No context found.

F. Yellin. Low level security in Java. In O'Reilly and Associates and Web Consortium (W3C), editors, World Wide Web Journal: The Fourth International WWW Conference Proceedings, pages 369--380. O'Reilly & Associates, Inc., 1995.

No context found.

F. Yellin. Low level security in Java. In O'Reilly and Associates and Web Consortium (W3C), editors, World Wide Web Journal: The Fourth International WWW Conference Proceedings, pages 369--380. O'Reilly & Associates, Inc., 1995. 13

No context found.

Yellin F. Low level security in Java. Proceedings of the 4th International World Wide Web Conference. O'Reilly & Associates, 1995; 369--379. http://java.sun.com/sfaq/verifier.html.

No context found.

Yellin, F.: 1995, `Low Level Security in Java'. In: World Wide Web Journal: The Fourth International WWW Conference Proceedings. Cambridge, MA, pp. 369--380.

No context found.

YELLIN,FRANK. 1995 (Dec.). Low Level Security in Java. In: Fourth International Conference on the World-Wide Web.

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC