Java 2 Platform Security

1. Java 2 Platform Security by Niels Damgaard Systematic

2. About me • Aug 1997 - Sep 2001: PhD student at BRICS • Supervisor: Michael Schwartzbach • Thesis: Using Theory to Make Better Tools • Topics: • Parser generation • Static analysis of assembly code on micro controllers • Security in interactive web services • Using generic algorithms to build neural networks • Sep 2001 - : Systems Engineer at Systematic Niels Damgaard Java 2 Security 2

3. Systematic • “Systematic Software Engineering A/S is a Danish, privately owned software house that focuses on complex IT solutions within information and communications systems.“ • “Our customers include defense institutions and suppliers as well as data communications, transportation and manufacturing companies and organisations in the finance and health care sectors.” • “Our services include software development of customer specific solutions and license sales of self-developed products, as well as consultancy and services in connection with user training, installation and support.” • “We have subsidiaries in Great Britain and the USA and employ more than 260 people.” • The headquarters of Systematic is in Frichsparken in Århus Niels Damgaard Java 2 Security 3

4. FlexCCIS • Framework for command, control, communication and information systems on ships • First application is a command control system for the Danish Navy’s Standard Flex 300 ships • A command control system is the software distinguishing a Navy ship from ferry: Radar, communication, recording, simulation, weapons etc • A ship contains servers, workstations and embedded computers in a network • FlexCCIS is written in Java 2 Standard Edition and Java 2 Micro Edition • A project like this is surprisingly complex and challenging. The complete system is estimated to 165.000 man-hours (100 man-years). Niels Damgaard Java 2 Security 4

5. Plan Thu 11. April: Java 2 Security Platform Man 15. April: Canceled (No exercises) Thu 18. April: Java 2 Security Platform Man 22. April: Canceled (No Exercises) Niels Damgaard Java 2 Security 5

6. Talk outline • Introduction • Security Architecture Basics • Customizing the Security Architecture • Object Security • Cryptography Architecture • Security Tools • Security news in JDK 1.4 • Future Directions Niels Damgaard Java 2 Security 6

7. Material • The lectures are based on the book“Inside Java 2 Platform Security” by Li Gong • Li Gong is the Chief Java Security Architect at Sun • See my review of the book in Datalogbladet or onwww.datalogforeningen.dk Niels Damgaard Java 2 Security 7

8. Java Versions • Java 1.0The Sandbox • Java 1.1Signed Applets • Java 2Fine-grain access controlImplemented in JDK 1.2, 1.3 and 1.4 Niels Damgaard Java 2 Security 8

9. How Java is Used • Write the program in Java • Compile the code to bytecode • Run the bytecode • Verify the bytecode • Execute the bytecode in a virtual machine • Safe and platform-independent • Large standard class library • Well-suited for large projects • Fairly slow Niels Damgaard Java 2 Security 9

10. Java Language • Strongly typed • No unsafe constructs (no buffer overflow) • Garbage collection (no free) • Designed so the programmer is less likely to make subtle mistakes • Platform independence (no porting bugs) • Compiled into bytecode Niels Damgaard Java 2 Security 10

11. Bytecode Verifier • Protects against malicious handwritten code • Ensures that only legitimate code is executed • No violation of language rules • Memory management is correct • No stack under/overflow • No illegal type cast • It doesn’t forge pointers • Methods are called correctly • Private fields are respected • Objects are accessed as what they are Niels Damgaard Java 2 Security 11

12. Sandbox • It is built into the Java Virtual Machine • It protects against malicious code • Applets run in a restricted environment • They can’t do potentially dangerous thingsFor example: access the harddisk • Applets can be given extra permissions by the user based on code signatures and code location • Applets can run in appletviewer or in a browser • Java applications run outside the sandbox Niels Damgaard Java 2 Security 12

13. Java Virtual Machine • The bytecode verifier together with runtime checks ensure that an applet can’t corrupt part of the security mechanism • An applet can’t interfere with the running of other Java programs • Access to crucial system resources is mediated by the virtual machine Niels Damgaard Java 2 Security 13

14. Why a New Security Arch.? • Java 1.0 sandbox restriction too limiting • Need flexible access control (Java 1.1) • Need fine-grained access control (Java 2) • Policy are used to grant permissions to running code • Attempts to access a protected resource leads to a security check (granted compared to needed perm.) • Permissions are based on code signatures and location • Security checks are easily extensible • Security enforcement mechanism separated from the policy Niels Damgaard Java 2 Security 14

15. Security Policy • Says what system resources that can be accessed, in what fashion, and under which circumstances • The security policy is an ASCII file (usually) in ~/.java.policy (becomes a Java object) • A piece of Java code is fully characterized by • Its origin (URL) e.g. http://java.sun.com/foo.jar • Its set of digital signatures • Any number of files in a JAR file can be signed • An entry in the policy is CodeSource, Permission • Wildcards are allowed Niels Damgaard Java 2 Security 15

16. Permissions • The permissions are positive, they grant access rather than deny access • By default, nothing extra is allowed Permission AllPermission FilePermission SocketPermission BasicPermission PropertyPermission AWTPermission RuntimePermission SecurityPermission Niels Damgaard Java 2 Security 16

17. Permissions • Permissions often have two arguments:target & set of actions e.g. /tmp/foo.txt, write • Applications are free to introduce new categories of permission • I will go through some of the permission classes Niels Damgaard Java 2 Security 17

18. FilePermission • The targets: file, directory, directory/file, directory/*, *, directory/-, “<<ALL FILES>>” • The actions: read, write, execute, delete • Example: /tmp/-, read ; /tmp/scratch/foo, writeThere is now read and write access to the file foo • The targets can be given in a platform-dependent format e.g. “c:\\temp\\foo” Niels Damgaard Java 2 Security 18

19. SocketPermission • Represents access to a network via sockets • The target host is specified with DNS name or IP address along with a portnumber (range) • The actions are accept, connect, listen, resolve • Resolve is implied by any of the other actions Niels Damgaard Java 2 Security 19

20. PropertyPermission • Represents the permission to access various Java properties • Target examples: java.home, os.name, user.name • Actions: read (getProperty), write (setProperty) Niels Damgaard Java 2 Security 20

21. BasicPermission • Base class for named permissions • A named permission contains a name instead of target, action-set • Examples: exitVM, queuePrintJob Niels Damgaard Java 2 Security 21

22. RuntimePermission • Named permission • Examples: exitVM, stopThread, modifyThread, setSecurityManager, writeFileDescriptor • Another example: loadLibrary that gives permission to link in native libraries that are not under JVM’s supervision Niels Damgaard Java 2 Security 22

23. AWTPermission • Named permission • Examples: accessClipboard, accessEventQueue, readDisplayPixels Niels Damgaard Java 2 Security 23

24. NetPermission • Named Permission • Examples: requestPasswordAuthentication, specifyStreamHandler Niels Damgaard Java 2 Security 24

25. SecurityPermission • Controls access to security-related objects • Examples: getPolicy, setPolicy, insertProvider, addIdentityCertificate, getSignerPrivateKey, setSignerKeyPair Niels Damgaard Java 2 Security 25

26. AllPermission • Represents all permissions • Use with care Niels Damgaard Java 2 Security 26

27. Pitfalls • Granting write access to the entire file system is effectively the same as granting AllPermission • Granting loadLibrary permission also effectively grants everything Niels Damgaard Java 2 Security 27

28. Assigning Permissions • The permissions of a class are calculated at load time from the Policy object • But it can be delayed until the first security check • Permissions are granted to classes, not objects • Permissions are additive. For example: code signed by A gets permission X andcode signed by B gets permission Y gives thatcode signed by A and B gets permission X and Y • Only positive permissions • In total it gives flexibility, simplicity, and good performance Niels Damgaard Java 2 Security 28

29. ProtectionDomains • Permissions can be granted to Protection Domains • Each class belongs to one and only one protection domain • Classes in a protection domain inherits the granted permissions • The original sandbox is a protection domain with a fixed boundary • The system domain has all permissions • They can also be used to isolate units of protection within the virtual machine, for example to prevent interaction Niels Damgaard Java 2 Security 29

30. Secure Class Loading • Lazy loading: on demand at the last moment • Dynamic loading: type safety maintained by link-time checks • The programmer can define new class loaders and assign appropriate security checks to these • Every class has a defining class loader by which it was loaded • A primordial class loader bootstraps the class loading process • There is a lot about it in the book Niels Damgaard Java 2 Security 30

31. Security Manager • It is called whenever the VM wants to decide whether to grant or deny a request for accessing a sensitive resource • In Java 1.0, it implements the sandbox • The way a security check is performed: • See if there is a SecurityManager installed • If there is, call the appropriate check() on it • The SecurityManager is thereby given an opportunity to prevent completion of the operation by throwing an exception Niels Damgaard Java 2 Security 31

32. Security Manager Example public FileInputStream (String name) throws FileNotFoundException { SecurityManager security = System.getSecurityManager(); if (security != null) { security.checkRead(name) } << proceed to open the file for read >> } • Note, this is system code Niels Damgaard Java 2 Security 32

33. Access Controller • By default, SecurityManager invokes methods defined in AccessController and essentially delegates the security decision making • The current execution context is the sequence of method invocations (i.e. the call stack) • Each method invocation belongs to a protection domain • “A request for access is granted if, and only if, every protection domain in the current execution context is granted the said permission.” Niels Damgaard Java 2 Security 33

34. Access Controller Example • Suppose that a game applet wants to read the high score file • That could give the following call stack: AccessController.checkPermission() SecurityManager.checkPermission() SecurityManager.checkRead() java.io.FileInputStream() openHighScoreFile() ... • There are two protection domains: system, applet • The read succeeds iff it is allowed in the applet PD • One doesn’t get extra permissions by calling system code Niels Damgaard Java 2 Security 34

35. Access Controller • Principle of least privilege • It can be too restrictive • For example: one can’t make a change password application that can be called from user code • That can be done by using doPrivileged() • It says that the status of its callers should be ignored • Note that it doesn’t gain any extra permissions • Be careful not to leak information and not to provide an unintended handle to other code Niels Damgaard Java 2 Security 35

36. Customizing theSecurity Architecture Niels Damgaard Java 2 Security 36

37. Creating New Permissions • Can’t change the built-in permission types • Can make a class that extends one of the existing permission classes • The new permissions can be referred to in the policy Niels Damgaard Java 2 Security 37

38. New Permission Example Java Code: public class com.abs.Permission extends java.security.Permission { ... } public class com.abs.TVPermission extends com.abc.Permission { ... } public void switchChannel (int channel) { com.abc.TVPermission tvperm = new com.abc.TVPermission(channel, “watch”); AccessController.checkPermission(tvperm); ... } Policy: grant { permission com.abc.TVPermission “5”, “watch”; } Niels Damgaard Java 2 Security 38

39. Security Manager Example • File access only during office hours public class TimeOfDaySecurityManager extends SecurityManager { public void checkPermission (Permission perm) { if (perm instanceof FilePermission) { Date d = new Date(); int i = d.getHours(); if ((i >= 9) && (i<17)) super.checkPermission(perm); else throw new SecurityException(“Out of office hour”); } else super.checkPermission(perm); } } • Applications can use TimeOfDaySecurityManager instead of the default Security Manager Niels Damgaard Java 2 Security 39

40. Security Manager Example2 • Record resource accesses public class AuditSecurityManager extends SecurityManager { public void checkPermission (Permission perm) { try { super.checkPermission(perm); Audit.enterRecord(perm, true); } catch (SecurityException e) { Audit.enterRecord(perm, false); throw e; } } } Niels Damgaard Java 2 Security 40

41. Security Manager Extensions • Multi-level security can be implemented • JVM has to keep track of object interaction • The Chinese Wall (separation of duty) model could also be implemented • JVM has to monitor object interaction and keep record of it • Research and experimentation is still needed in this area Niels Damgaard Java 2 Security 41

42. ObjectSecurity Niels Damgaard Java 2 Security 42

43. Fields and Methods • Never make public fields or variables that can be accessed directly • When using access methods it is also easier to extend with security check in a later release private TimeZone defaultZone=null; public synchronized void setDefault (TimeZone zone) { AccessController.checkPermission (new TimeZonePermission(“setDefault”)); defaultZone = zone; } • Unless a package is sealed properly an attacker may be able sneak in a class Niels Damgaard Java 2 Security 43

44. Static Fields • Static fields can cause unintended interaction between supposedly independent subsystems • Anyone can access the fields through the class name without an object reference • Directly exposed non-final public static variables are bad news for security • Make them private static and have public static access methods (perhaps with security check) Niels Damgaard Java 2 Security 44

45. Object Mutability public class MyClass { private boolean[] status = null; public boolean[] getStatus() { return status; } } • Anybody can change status behind the back of MyClass • Return clones of mutable objects! • Examples of mutable objects: arrays, Vector, Hashtable • Use char[] (instead of String) to store passwords, wipe it manually after use Niels Damgaard Java 2 Security 45

46. Serialization • Used to transport classes and objects to other computers or to store them on the harddisk • For example used by the Java Remote Method Invocation (RMI) package • writeObject() serializes the object and readObject() deserializes the object • If the objects have any invariants provide a readObject() that checks the invariants • Private fields can be read and changed while it is being transported over the network • SignedObject and SealedObject can protect serialized objects Niels Damgaard Java 2 Security 46

47. SignedObject • A SignedObject contains the object in serialized form and a signature of it • The object has to be serializable • Provides object integrity and authenticity • Note: this is different from signed JAR files! Niels Damgaard Java 2 Security 47

48. SealedObject • SealedObject contains the encryption of the serialized object • Protects an objects confidentiality • Can be combined with SignedObject to provide both authenticity, integrity and confidentiality • Sign first! It is harder to attacker Niels Damgaard Java 2 Security 48

49. GuardedObject • Can be used for object-level access control • It is used to protect access to another object • 1: Request access2: Check guard3: Return the object reference • For example useful when supplier and consumer are in different threads • Normal security checking doesn’t work because they don’t share execution context 1 Guard 2 Requestor 3 Protected GuardedObject Niels Damgaard Java 2 Security 49

50. Java Cryptography Architecture Niels Damgaard Java 2 Security 50