Java modes of use
- Applets: Auto-run when view web page
- Applications: Traditional program
- Beans: Component (like OLE object)
- Servlets: Server-side applications
- Aglets: Intelligent Agents
- Doclets: Configurable doc generator
- Embedded Systems
- Smart Cards (“JavaCard”)
Security Related Capabilities of Java
JDK 1.0 (Fall 1995)
Policy: “Sandbox” for applets; others unlimited
Mechanisms: SecurityManager, Bytecode verifier, Classloader
JDK 1.1 (Spring 1997)
Policy: can also grant total trust to signed applets
Mechanisms: Java Archive (JAR), crypto-related APIs
Inflexible: Too little or too much privilege
Netscape & Microsoft Extensions
Enabled more flexible approaches
Incompatible with each other and with Sun
J2SE (Java 2 Platform Standard Edition) (Fall 1998)
Includes SDK 1.2 and runtime
Policy: can also grant fine-grained privileges to specific applets/classes based on source and/or signatures
Mechanisms: AccessController, ProtectionDomain, CodeSource, Permission, GuardedObject, …
“Java Plug-in” supports both Microsoft & Netscape
Java 1.0 Security Policy
Sandbox Policy (for applets)
Cannot access local filesystem or devices
Network connections only to applet load source
Cannot invoke any local program or library
“Untrusted” indicator on top-level windows
Cannot manipulate basic classes or another ThreadGroup
Appletviewer CL can be initialized to vary these
Applications unlimited in 1.0; can code a policy
Security Manager
Class defines check methods called by system
E.G. “checkRead(String filename)”
Method throws exception if invalid
To create a security policy from scratch:
Create a subclass (code) & instantiate
Install using System.setSecurityManager; this cannot be revoked or replaced
This is used to create the Sandbox
If no SecurityManager installed, all privileges granted
Source: Java Security & Java Developers
0 comments:
Post a Comment