Enterprise Security Series

1. Enterprise Security Series Java 2 Security Ram Rao March 15th ‘05

2. 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.

3. 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

4. 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.

5. 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

6. 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

7. Class Loader Responsibilities: • Name-space separation • Package boundary protection • Access-rights assignment • Search-order assignment

8. Class file verifier Responsibilities • Illegal pointers, byte-code instructions • Stack overflow/underflow check • Illegal casting • Illegal code-base access

9. 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

10. Security Manager • Functional class between programs and J2SE security access-control • Policy driven security model • Permissions and access control

11. Java 2 Permissions Model • Permissions API • Concepts like Policy, CodeSource, ProtectionDomain • Access-control architecture • Privileged code

12. 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()

13. 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

14. 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.

15. 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.

16. 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

17. 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"; };

18. 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"; };

19. 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%)

20. Java 2 Security Impact - Operations • Policy management (Static and Dynamic) • Skills • Policy enforcement. • Code review

21. Resources • Permissions in Java2 SDK • http://java.sun.com/j2se/1.4.2/docs/guide/security/permissions.html • WAS 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