Java 2 Platform Security
• Java is capable of confronting a number of security concerns through various mechanisms.
- Java Security API’s (JCA, JCE, JSSE, JAAS)
- Configurable policies that deal with controlling Java applications’ access to a system’s files, printers,
ports.
- The ability to generate keys, message digests and digital certificates.
• The Java 2 platform addresses a vast and very broad range of topics dealing with security.
- This is largely due to the fact that ‘security’ can (and does) mean so many different things.
- Also, because Java is intended to be flexible and extensible, it needs to be able to conform to the
seemingly endless list of required duties in an enterprise environment.
• This chapter briefly addresses basic Java platform concepts that relate to security.
• The remaining chapters focus on the security-related Java API’s and concepts that apply to application
security and data integrity.
• You can find most platform related concerns or questions at:
http://java.sun.com/security
Java Virtual Machine (JVM) and Sandbox
• Essentially, the sandbox is a generic term for mechanisms that protect the client by separating the JVM
and operating system by restricting and permitting only authorized or “safe” code execution.
- When we talk about parts of the JVM and setting policies – we’re also talking about the sandbox.
- The sandbox basically encapsulates all the security features of the Java platform.
• With the sandbox, code is divided into local code and remote code.
- Local code is already installed to the system and therefore trusted, by default.
- Remote code (such as an applet) is downloaded or executed remotely and not trusted, by default.
• The Java Virtual Machine essentially has the following security features:
- Bytecode verifier
- Class loader
- Security manager/Access controller
• The bytecode verifier checks to make sure that class files that are loaded into the JVM follow the rules
of the Java language.
- Makes sure that code loaded into the JVM will not perform malicious actions such as eating up
memory or using variables that haven’t been initialized.
- Note that just because code goes through the bytecode verifier doesn’t mean that it hasn’t been
tampered with.
• The class loader reads in and loads class files into the JVM.
- This allows classes to be instantiated.
- Permissions can be set as classes are loaded.
• The security manager and access controller separates the JVM from the operating system.
- Depending on policies (default or user specified), the security manager and the access controller handle
restrictions and/or access to system resources.
• Java is capable of confronting a number of security concerns through various mechanisms.
- Java Security API’s (JCA, JCE, JSSE, JAAS)
- Configurable policies that deal with controlling Java applications’ access to a system’s files, printers,
ports.
- The ability to generate keys, message digests and digital certificates.
• The Java 2 platform addresses a vast and very broad range of topics dealing with security.
- This is largely due to the fact that ‘security’ can (and does) mean so many different things.
- Also, because Java is intended to be flexible and extensible, it needs to be able to conform to the
seemingly endless list of required duties in an enterprise environment.
• This chapter briefly addresses basic Java platform concepts that relate to security.
• The remaining chapters focus on the security-related Java API’s and concepts that apply to application
security and data integrity.
• You can find most platform related concerns or questions at:
http://java.sun.com/security
Java Virtual Machine (JVM) and Sandbox
• Essentially, the sandbox is a generic term for mechanisms that protect the client by separating the JVM
and operating system by restricting and permitting only authorized or “safe” code execution.
- When we talk about parts of the JVM and setting policies – we’re also talking about the sandbox.
- The sandbox basically encapsulates all the security features of the Java platform.
• With the sandbox, code is divided into local code and remote code.
- Local code is already installed to the system and therefore trusted, by default.
- Remote code (such as an applet) is downloaded or executed remotely and not trusted, by default.
• The Java Virtual Machine essentially has the following security features:
- Bytecode verifier
- Class loader
- Security manager/Access controller
• The bytecode verifier checks to make sure that class files that are loaded into the JVM follow the rules
of the Java language.
- Makes sure that code loaded into the JVM will not perform malicious actions such as eating up
memory or using variables that haven’t been initialized.
- Note that just because code goes through the bytecode verifier doesn’t mean that it hasn’t been
tampered with.
• The class loader reads in and loads class files into the JVM.
- This allows classes to be instantiated.
- Permissions can be set as classes are loaded.
• The security manager and access controller separates the JVM from the operating system.
- Depending on policies (default or user specified), the security manager and the access controller handle
restrictions and/or access to system resources.
Java Platform Security
Table of Contents
Copyright (c) 2008. Intertech, Inc. All Rights Reserved. This information is to be used exclusively as an
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Courseware
Training Resources
Tutorials