Enterprise Security Series
Post on 02-Jan-2016
39 Views
Preview:
DESCRIPTION
Transcript
Enterprise Security Series
Java 2 Security
Ram Rao March 15th ‘05
Objective
Explain Java2 Security Describe various low-level JVM components
and their functions. Describe use in Enterprise Security
* Uses Websphere Application Server (WAS) for illustration.
Introduction
Security model for Java code. J2EE security build on top of J2SE security Independent of J2EE Provides JVM-level security Excludes distributed security Uses Websphere Application Server
Capabilities/Drivers Fine-grained access control:
• Code with proper permissions is allowed to step outside the sandbox constraints.
Configurable security policy: • Configure and manage complex security policies.
Extensible access control structure: • Allow typed permissions
• Group such permissions in logical, policy-oriented constructs.
Security checks for all Java programs:• Check everything. Don’t even trust yourself.
Primary Components
Language-level• public/private/protected class members.
Class Loaders • Manages loading/unloading of code
Class file verifier• Checks byte code for type safety violation
Security Manager• Provides runtime checks
• Threads, I/O, Network
• One per JVM
Language-level restriction
Built around Object oriented design Private member
• Restricted to class
Protected member• From anywhere in the package and subclasses.
Default (no attribute)• Only from within the package.
Public • Any java code
Class Loader
Responsibilities: Name-space separation Package boundary protection Access-rights assignment Search-order assignment
Class file verifier
Responsibilities Illegal pointers, byte-code instructions Stack overflow/underflow check Illegal casting Illegal code-base access
Security Manager
Types of runtime attacks
System modification• Read/write access to system resources
Invasion of privacy• Read/write access to secure resources
Denial of Service• Exhaust system resources
Impersonation• Pretends to be someone
Security Manager
Functional class between programs and J2SE security access-control
Policy driven security model Permissions and access control
Java 2 Permissions Model
Permissions API Concepts like Policy, CodeSource,
ProtectionDomain
Access-control architecture Privileged code
Java 2 Security and J2EE
Java2 security restrictions are enforced on a large set of APIs, especially low-level socket openers etc.
No spawning of threads from servlets/EJBs EJBs have no file system access Servlets have restricted file system access Can’t call getUserPrincipal()
Java 2 Security and WAS
Leverages Java 2 SecurityManager Disabled by default. Can be turned off even if WAS Global
security is enabled. Global Security has to be enabled to
enable Java 2 Security Custom policy files. In-built debugging support
Security Policy Files – Static Policy
Not managed by configuration. Changes are local.
java.policy - install_root/java/jre/lib/security/java.policy Default permissions granted to all classes. The policy applies to all the processes launched by the WebSphere Application Server
server.policy - install_root/properties/server.policy Default permissions granted to all the product servers
client.policy - install_root/properties/client.policy Default permissions for all of the product client containers and applets on a node.
Security Policy Files – Dynamic Policy
Resource-based. Dynamically calculated during runtime.
app.policy - For all of the enterprise applications in the cell.was.policy - Application-specific. Packaged in EAR. ra.xml - Connector application specific. spi.policy - For Service Provider Interface (SPI). Applies to
all of the SPIs defined in the resources.xml file.library.policy – For shared library of enterprise app.filter.policy - Permissions that require filtering from the
was.policy file and the app.policy file in the cell. Only applies to the was.policy and app.policy files.
Dynamic Policy – was.policy
file:${application} – Whole application
file:${jars} - Apply to all utility Java archive (JAR) files within the application
file:${ejbComponent} - Apply to enterprise bean resources within the application
file:${webComponent} - Apply to Web resources within the application
file:${connectorComponent} - Apply to connector resources within the application
Dynamic Policy – was.policy contd..
e.g.
"file:xyz.war" { permission java.security.SecurityPermission "printIdentity"; };
grant codeBase "file:xyz.jar" { permission java.io.FilePermission "${user.install.root}${/}bin${/}DefaultDB${/}-", "read,write,delete"; };
Dynamic Policy – library.policy
Used for shared Java library classes
To change library sharing policy within a cell.
e.g. grant codeBase "file:<client localtion>" { permission
java.io.FilePermission "C:\WebSphere\AppServer\java\jre\lib\ext\mail.jar", "read"; };
Java 2 Security Impact - Development
Limits OS file system access. Prevents access to WAS administrative APIs. Prevents access to a large set APIs (see
Resources for list). Prevents access to files of WAS internal and
application resources. Developers need to be Java2 Security aware.
Not an easy skill. Comes at a performance cost(10%-20%)
Java 2 Security Impact - Operations
Policy management (Static and Dynamic)
Skills Policy enforcement. Code review
Resources
Permissions in Java2 SDK• http://java.sun.com/j2se/1.4.2/docs/guide/security/
permissions.htmlWAS Security
• http://publib.boulder.ibm.com/infocenter/ws51help/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/csec_rpolicydir.html
Java Security• Enterprise Java Security – Pistoia et al, Addison-
Wesley
top related