Java 2 Security. Dean Wette Senior Software Engineer Object Computing, Inc.

Transcription

1 Java 2 Security Dean Wette Senior Software Engineer Object Computing, Inc. St. Louis Java Users Group, 11 Oct University of MO-Rolla, Computer Science Colloquium, 1 Nov. 2001

2 Overview Java Platform designed with security a chief concern some other mainstream environments implement security as an afterthought and we know how well that works! Security in the Java Environment language and core APIs compiler class file verifier class paths & class loaders Java Virtual Machine (JVM)

3 Types of Java Security Control Code-centric security (J2SE) constrain code from accessing sensitive or privileged system resources security constraints applied to classes User-centric security (JAAS) authentication verifies identity authorize execution of code by authenticated principals Cryptography (JCA/JCE/JSSE) enforce integrity and secrecy of data

4 Brief History Java 1.0.x Applets run in Sandbox local code fully trusted Java 1.1.x remote code trusted if digitally signed allows privileged Applets Java 2 all-or-nothing binary trust Permissions -based trust fine-grained policy-based access control trust can be fine-tuned for all programs

5 Java 2 Security Model A much improved and more flexible security model for Java programs easily configurable security policy extensible access control structure separation of enforcement mechanism from policy statement customization much easier no need to subclass SecurityManager involves creating new Permission classes and using them in a policy statement

6 Java Program Execution Certain types of Java programs run with a security manager Applets browsers enforce this Java Plug-in RMI RMILoader won t load remote classes without a security manager Java Web Start J2EE Containers still evolving Java applications run without a security manager by default

7 Installing a Security Manager With the java command: java Djava.security.manager MyApplication Programmatically: public class MyApplication { public static void main(string[] args) { SecurityManager sm = new SecurityManager(); System.setSecurityManager(sm); // SecurityManager in effect from here on... but not both!

8 The Security Policy Represents persistent statements of permission, granted to code source, for access to specified privileged resources file-based by default defines a keystore of digital certificates defines grant statements applied to code (classes) according to: where the code originated (its source) whether or not it is digitally signed, and by whom grant statements specify one or more permissions given to designated code

9 Policy Files Java 2 includes a default system policy file located in ${java.home}/lib/security/java.policy grants full trust to optional packages grants read access to certain Java properties and defines a user policy file located (but not created by default) in ${user.home}/.java.policy policytool, a GUI policy configuration tool helps prevent syntax errors that negate a policy

10 Program Policy Files Additional policy files can also be defined, either permanently or temporarily with an entry in the security properties file ${java.home}/lib/security/java.security using the java command java Djava.security.policy=<url> java Djava.security.policy==<url> append to default policies override default policies

11 A Sample Policy File keystore ${user.home}/.keystore, JKS ; java property expansion grant codebase file:/${user.home}/trusted/* { permission java.security.allpermission; }; grant signedby dwette, codebase { permission java.util.propertypermission user.home, read ; permission java.io.filepermission ${user.home}${/}prefs.xml, read,write ; permission java.net.socketpermission *.wettenet.net:5050, connect,resolve ; };

12 Security es in a Nutshell java.security.codesource encapsulates code location & signers java.security.protectiondomain maps a set of classes to granted permissions java.security.policy the runtime representation of the policy statement not involved with making access control decisions java.lang.securityexception java.security.accesscontrolexception

13 Security es (cont d) java.lang.securitymanager represents the focal point of access control called by operations when decision is needed to grant code access to protected resources defines the interface for checking permissions java.security.accesscontroller provides the actual access control algorithms called by the SecurityManager but may also be called directly for access control

14 Permissions Represent privileged access to resources, granted to running code. permissions are access approvals, not denials Three general properties: 1. type: identifies what the permission pertains to 2. name: identifies the target for an instance of a specific permission type 3. actions: varies, and is dependant on semantics of permission type name and actions support wildcard matching

15 Permission es java.security.permission abstract ancestor of all permission classes specifies essential functionality java.security.basicpermission fully implemented abstract subclass of Permission used as a base class for many other permissions java.security.allpermission represents permission to perform any operation effectively, a grant of every possible permission

16 Permission Collections java.security.permissioncollection represents a homogeneous collection of Permission objects (i.e. of same class type) java.security.permissions represents a heterogeneous collection of Permission objects is both a subtype and composition of PermissionCollection Note: ProtectionDomain objects map a CodeSource to a PermissionCollection (actually a Permissions) object.

17 Standard Permission es

18 Optional Package Permissions

19 Lifecycle of a Permission Check What happens when code requests access to protected resources?... FileWriter fw = new FileWriter(userHome + File.separator + prefs.xml );... public class FileWriter { either returns silently, or... throws a SecurityException public FileWriter(String filename) { SecurityManager sm = System.getSecurityManager(); if (sm!= null) { sm.checkpermission(new FilePermission(fileName, read )); } // permission granted, continue...

20 Lifecycle (cont d) // java.io.filewriter class... public FileWriter(String filename) { SecurityManager sm = System.getSecurityManager(); if (sm!= null) { sm.checkpermission(new FilePermission(fileName, read )); }... } // java.lang.securitymanager class SecurityManager delegates to AccessController to perform public class SecurityManager { the actual permission check... public checkpermission(permission perm) { AccessController.checkPermission(perm); } }

21 Lifecycle (cont d) By the time all this occurs: 1. The persistent policy has been bootstrapped into a single Policy instance 2. loaders have associated loaded classes with ProtectionDomain objects (CodeSource objects mapped to PermissionCollection objects) What happens in the method AccessController.checkPermission the access controller consults the policy in effect to determine if the permission being checked is implied by the policy (and can be granted) and this leads to two important concepts...

22 Principal of Least Privilege A request for access is granted if, and only if, every protection domain in the current execution context is granted the said permission. 1 if a caller calls code with more privileges, the caller doesn t gain any privileges as a result, and calling less privileged code results in loss of privilege This leads to the access control algorithm...

23 Access Control Algorithm The access controller looks at the protection domain of every class involved in the current sequence of method calls. So given an execution stack of n callers: for (i = n; i > 0; --i) { access control context if (caller i s protection domain does not have permission) throw a security exception } return normally

24 Viewed Another Way... new FileWriter(... protection domain protection domain protection domain protection domain protection domain protection domain protection domain protection domain access controller program entrypoint

25 Permission Implication How does the access controller test a finegrained permission request against a more loosely-grained policy? For example: have this permission grant { permission java.io.filepermission( ${user.home}/*, read, write ; }; need this permission vs. Permission fp = new FilePermission(userHome + / + xmlpreffile, read ); AccessController.checkPermission(fp);

26 Permission Implication (cont d) All Permission classes, and the permission collection classes, define the method: boolean implies(permission p) not an equality test, but more of a subset test used by the access controller to determine if one permission, or a collection of permissions, (i.e. in the policy) implies another one (i.e. the one being checked) two Permission objects are equal if, and only if, they imply each other

27 Privileged Blocks Consider again the access control algorithm... Suppose: you want trusted code to perform privileged operations on behalf of less trusted code, but... the access control algorithm is contrary to this Solution: mark a trusted block of code privileged such that: it takes responsibilty for permissions it has, and it tells the access controller to ignore its callers

28 trusted code untrusted code new FileWriter(... access controller program entrypoint

29 Access Control Algorithm (Rev.) The access control algorithm revisited... for (i = n; i > 0; --i) { if (caller i s protection domain does not have permission) throw a security exception if (caller i s protection domain is marked privileged) return normally } return normally

30 program entrypoint trusted code untrusted code new FileWriter(... access controller calls method with priviliged block

31 Privileged Blocks (cont d) The implementation: static methods in AccessController Object doprivileged(privilegedaction action); Object doprivileged(privilegedexceptionaction action) throws PriviledgedActionException; public interface PrivilegedAction { public Object run(); } public interface PrivilegedExceptionAction { public Object run() throws Exception; }

32 Example Privileged Block untrusted code calls this public void savepreference(final String key, final String val) throws IOException { be wary of try { tainted variables AccessController.doPrivileged(new PrivilegedExceptionAction() { public Object run() throws IOException { dosavepreference(key, val); delegate sensitive return null; operation to class } private method }); } catch (PrivilegedActionException pae) { throw (IOException)pae.getException(); } IOException thrown } by run() is wrapped

33 Summary Java 2 provides a policy-based, fine-grained access control security model. Permissions are assigned to code, based on where it came from, and whether and by whom it was digitally signed. The semantics of permissions are represented by the Permission class and its subtypes. Permissions are associated with protection domains assigned to classes by class loaders.

34 Summary (cont d) The access control algorithm is based on the Principal of Least Privilege. The access controller tests permission implication rather than equality. Privileged blocks provide the mechanism for trusted code to perform sensitive operations on behalf of less trusted code.

35 References architect of the Java 2 security model 1. Gong, Li. Inside Java 2 Platform Security: Architecture, API Design, and Implementation. Addison-Wesley Oaks, Scott. Java Security, 2 nd ed. O Reilly Pistoia, Marco, et al. Java 2 Network Security, 2 nd ed. Prentice-Hall Sun Microsystems. Java 2 Standard Edition Documentation Version Wette, Dean. Java 2 Platform Security. Object Computing, Inc