The security mechanisms of Java

Transcription

1 The security mechanisms of Java Carlo U. Nicola, SGI FHNW With extracts from publications of : Sun developers' center documentation; David A. Wheeler, UC Berkeley; Klaus Ostermann, TH-Darmstadt.

2 Topics 1. The Java 2 security model 2. The wrapper Java 3. The real boss: 4. Java class 5. Java policy files 6. Protection domains in Java 7. Smallest security s units in Java AS HS12 2

3 Security Model: OpenXML and Java Java PEP: Java PAP! File: Java PIP! File: Java PDP: AS HS12 3

4 Java security in a nutshell Bytecode + Class loader security up with : set Java Core local libraries class-files are not Bytecode verified Activated by: or programmatically AS HS12 4

5 The Java security check algorithm Repeat Check if current method has the requested permission If not, throw n. Check if current method has amplified privileges. If so, grant permission. Consider calling method (move up call stack) Until call stack is empty From: Check if thread inherited the requested permission. If not, throw. If yes, grant permission. From: Protection domain Protection Domain: Stores in a per thread variable the intersection (Å) of the static permissions of all methods invoked since its start, and grant permission on the result of that intersection operation. AS HS12 5

6 The It is an historical flotsam: actually it is a wrapper who calls the AS HS12 6

7 What can the do? In the class there are:! methods that control access to files;! methods that control access to network resources;! methods that protect the JVM;! methods that protect system resources;! methods that protect security; For example in the System class, there are two methods to set up and use a custom made security manager: But setting a new security manager needs, besides a new System Manager, a permission in the file too. AS HS12 7

8 The method Since Java2 the ( ) class defines a new method ) that is called explicitly or implicitly as soon as the SM is activated:! Throws exception if does not hold, else returns;! All previous check methods are rewritten in terms of ;! Permits creation of new without changing the (as it was not the case with JDK1/0-1.1). By default now, it uses the class for its functionality. AS HS12 8

9 Example: A simple file write check (1) Start application with options: Calls implicitly AS HS12 9

10 Example: A simple file write check (2) Policy file: AS HS12 10

11 Security policy files in Java AS HS12 11

12 The Java security policy The fine-grained configurable policies for both Java Applet and Java applications are based upon the following techniques: A text file contains the custom security policy for an application: default file and file in At run time one or more of the following checks are made in dependence of the above policy : 1. Ã Ã Policy 2. Java 2 Runtime Security Check Algorithm (see slide 5) 3. class and its sub classes 4. and AS HS12 12

13 The structure of a file The security policy is an ASCII file (usually defined in ). It determines which system resources can be accessed and how they can be accessed. It becomes a Java object. The building blocks of a security policy are: 1. Origin and eventually authentication of a piece of code. Tag: :! An origin (URL) e.g.! A set of digital signatures: any number of files in a JAR can be signed. 2. An entry in the policy file is specified by : 3. Wildcards are allowed. AS HS12 13

14 Example The security manager operates according to the policy (defined in ) which consists of a set of rules, e.g. the default is: Or a more fine grained one: AS HS12 14

15 Creating a new policy file You may use to create or edit an existing policy file (but you can of course use any editor of your choice). The example policy file below grants two permissions: firstly, to the code signed by Duke the permission to read files located in the user's home directory, and secondly to the code from the location (regardless of who signed it) to read the system property. AS HS12 15

16 Managing policy files 1. By default, the JDK uses the policy files located in: 2. These policy files are specified in the default security file: 3. The final policy is the union of all granted permissions in all policy files. To specify an additional policy file, you can set the system property at the command line: or: 4. To ignore the policies in the file, and only use the specified policy, use ` ' instead of ` ': 5. Additional policy files can also be added to the file. For more information on policy files, see: AS HS12 16

17 The default java.policy file AS HS12 17

18 Example: an extension to AS HS12 18

19 Permissions in Java AS HS12 19

20 Permissions tree The permissions are positive, they grant access rather than deny access. By default, nothing extra is allowed. Two classes rule them: and AS HS12 20

21 : general template Permissions have often two arguments:! A target and! a set of actions e.g.: Applications are free to introduce new categories of permission AS HS12 21

22 : files Files: The targets: (recursively), The actions (one or more a.k.a 1+): Example: There is now read and write access to the file. The targets can be given in a platform-dependent format e.g. in Windows: AS HS12 22

23 : socket and properties Socket: Permissions to access a network via sockets:! The target host is specified with or along with a (or range ); (all hosts); (all hosts in domain)! The actions (1+):! Resolve is implied by any of the other actions. The action " " refers to host/ip name service lookups. Properties: Represents the permission to access various Java properties:! Target examples:! Actions (1+): AS HS12 23

24 : general layout and run time Basic permissions : Base class for named permissions: i.e. a permission that contains a name instead of a pair (target, action-set). Examples: (halting of the JVM! DoS), (initiation of a print job request) Run time permissions (named permission) :! Examples:! Another example: that gives permission to dynamic link in native libraries that are not under JVM s supervision. AS HS12 24

25 AWT permissions are named permissions: Examples: : AWT, net and security Net permissions are named permissions: Examples: (the ability to specify a stream handler when constructing a URL) Security permissions are named permissions. They control access to security related objects. Examples: AS HS12 25

26 Caveat emptor! a) Granting access to the entire file system is effectively the same as granting. b) Granting permission also effectively grants everything, because nobody knows exactly in which way the library depends upon the system's resources. AS HS12 26

27 Note on class class:! Encapsulates a permission granted or requested! Can be set read only (from then on immutable)! Can be grouped using classes and Jargon used in this context:! Permissions granted to a are also called privileges! But no separate Privilege class do exist. AS HS12 27

28 Creating new permissions 1. You can not change the built-in permission types; 2. You can make a class that extends one of the existing permission classes (see example below); 3. The new permissions must be referred to in the policy file. AS HS12 28

29 Using new permissions AS HS12 29

30 Policy file for new permission The file is defined as follows: AS HS12 30

31 Summary permissions 1. The permissions of a class are calculated at load time from the policy object. 2. But it can be delayed until the first security check. 3. Permissions are granted to classes, not to objects. 4. Permissions are additive. For example: code signed by A gets permission X and code signed by B gets permission Y code signed by A and B gets permission X and Y 5. Only positive permissions do exist: i.e. they always grant access and never deny access! AS HS12 31

32 Protections' domains AS HS12 32

33 class class Created from a and a Defines the set of permissions granted to classes; changes the to change permissions; Each class belongs to ONE instance, set at the class creation time (and never changed again); Access to these objects is restricted; getting its reference requires a. One can have more than one protection domain. AS HS12 33

34 Granularity: each class has a asks AS HS12 34

35 class This class extends the concept of a to encapsulate not only the location (URL) but also the certificate(s) that were used to verify the signed code originating from that location. Created from: A source (base) URL and An array of certificates This class is immutable. With the abstract method of the class one can implements URL partial matches: Permits policies to use URL patterns means that if one is granted permission a then one gets b too. AS HS12 35

36 class It provides an interface to the user policy i.e.: Given a, it returns a ; It is called during the setup stage of to set the class permissions. AS HS12 36

37 How a class and are loaded 1. A loaded class requests an unloaded class ; s is called, loads s class file, and calls the java byte code verifier; s is determined via java or user's security policy; 4. The policy object, given that, returns the class ; 5. If an existing has the same and, then it is reused, if this is not the case then a new is created and is assigned to it. AS HS12 37

38 Java 2 runtime security check algorithm If method requires the permission :! s implementation calls the current s method! By default this calls the class, which does the work and for each call stack entry, it unwinds from the caller: a) if the caller s lacks, an exception is thrown (fails); b) if the caller called the method without context, it executes and returns (dangerous); c) if the caller called the method doprivileged with context, it checks it and returns if context permits otherwise an exception is thrown (fails). AS HS12 38

39 Example 1. Multiple : of calls of that calls ; (in System s ) asks for a permission check; Permissions are checked against the s for, then for and finally for. Only if the intersection of all 3 sets contains the desired permission, is granted. call (without context): Same as above, but first calls When the permission check is requested, only the for is checked all others are not checked. AS HS12 39

40 Class Its method takes a snapshot of the current execution context ( stack trace ): The snapshot includes all ancestor threads; These contexts are stored in type ; The class itself has a method that makes access decisions based on the context it encapsulates. The results can be stored and used later to limit the privileges (instead of enabling all privileges). Its purpose: support actions on behalf of another one thread posts an event to another one delayed actions ( cron job) AS HS12 40

41 Algorithm implications Default privileges are the intersection (minimum) of all class permissions in the stack's call tree: Without, permissions that decrease the privilege are permitted (Principle of Least Privilege). enables all class privileges: Like Unix setuid ; it enables trusted classes to use their full set of privileges but only when requested; Without context it enables all privileges (dangerous!); With context it enables only those privileges that are also in the given context. This is a safe action because the resulting privileges are always less than those without context. AS HS12 41

42 Example : no context no return value Interface with only one method AS HS12 42

43 Example : no context but return value AS HS12 43

44 Example : with context AS HS12 44

45 Security hole 1. Fact: If a method is not overridden, the of its defining super class is used. 2. The consequence of this fact is obvious: Methods running (even indirectly) with privileges should not depend on protected variables! Why? Because a cracker could: a) create a sub class with a new method in which: b) method modifies a protected variable used by c) and so it causes to be invoked:! is influenced by! 3. Identified by David A. Wheeler Oct 1999 AS HS12 45

46 Java security at the method level AS HS12 46

47 (1) 1) To protect one method in all instances, use the + directly as we have shown so far. 2) To protect a reference to an individual instance, consider using the class : requesting class 1 3 reply with object-toguard 2 object-to-guard AS HS12 47

48 (2) The class encapsulates object-to-guard: asks interface to determine if the access is ok; Class implements by calling: doesn t implement it. A provider of object-to-guard does the following: Instantiates new (e.g., a ) Instantiates, using object-to-guard and the guard Gives s reference to requestors. Clients who wish to use object-to-guard call s : instance calls its s if ok, object-to-guard s reference is returned; if not ok, security exception is thrown. AS HS12 48

49 Use of This example demonstrates how to protect access to an object using a permission: AS HS12 49

50 Bibliography Li Gong, Inside Java 2 Platform Security (2 nd Edition), 2003, Palo Alto, CA: Addison-Wesley. G. McGraw & E. Felten, Java Security: Hostile Applets, Holes, and Antidotes, 1997, NY: John Wiley & Sons. G. McGraw & E. Felten, Securing Java: Getting Down to Business with Mobile Code, 1999, NY: John Wiley & Sons, Permissions in Java 7: AS HS12 50