The advent and popularity of Java has created a new paradigm: downloaded content can now also be executable. Java developers have tried to address security by implementing a few mechanisms, which are supposed to remove the risks of executing untrusted code:
Java developers have often promoted Java as a secure language. At the lowest level, security goes hand in hand with robustness. Java programs cannot:
Byte-code Verification
The second line of defense against malicious code is the byte-code verification procedure that the Java interpreter performs on any untrusted code it loads. The verification procedure should ensure that the code is well formed. For example, it should not overflow or underflow the stack or contains illegal byte-codes. If the byte-code verification step was skipped, inadvertently corrupted or maliciously crafted byte-codes might be able to take advantage of implementation weaknesses in a Java interpreter.
Java Sandbox
Another layer of security protection is commonly referred to as the sandbox model: untrusted code is placed in a sandbox, where it can play safely and without doing any damage to the real world, or the full Java environment. When an applet or other untrusted code is running in the sandbox, there are a number of restrictions on what it can do. The most obvious of these restrictions is that it has no access to the local file system.
Security Manager
The Security Manager class enforces a number of other restrictions. All the core Java classes that perform sensitive operations, such as file system access, first have to ask permission of the currently installed security Manager. If the call is being made by untrusted code, the security manager throws an exception, and the operation is not permitted.
- Memory access.
- The Java Sandbox.
- The Byte-code Verifier.
- The Applet Class Loader.
- The Security Manager.
Java developers have often promoted Java as a secure language. At the lowest level, security goes hand in hand with robustness. Java programs cannot:
- Forge pointers to memory
- Overflow arrays
- Read memory outside the bounds of an array or string
Byte-code Verification
The second line of defense against malicious code is the byte-code verification procedure that the Java interpreter performs on any untrusted code it loads. The verification procedure should ensure that the code is well formed. For example, it should not overflow or underflow the stack or contains illegal byte-codes. If the byte-code verification step was skipped, inadvertently corrupted or maliciously crafted byte-codes might be able to take advantage of implementation weaknesses in a Java interpreter.
Java Sandbox
Another layer of security protection is commonly referred to as the sandbox model: untrusted code is placed in a sandbox, where it can play safely and without doing any damage to the real world, or the full Java environment. When an applet or other untrusted code is running in the sandbox, there are a number of restrictions on what it can do. The most obvious of these restrictions is that it has no access to the local file system.
Security Manager
The Security Manager class enforces a number of other restrictions. All the core Java classes that perform sensitive operations, such as file system access, first have to ask permission of the currently installed security Manager. If the call is being made by untrusted code, the security manager throws an exception, and the operation is not permitted.
