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