1 / 88

Java 2 Platform Security

Java 2 Platform Security. by Niels Damgaard Systematic. About me. Aug 1997 - Sep 2001: PhD student at BRICS Supervisor: Michael Schwartzbach Thesis: Using Theory to Make Better Tools Topics: Parser generation

carter
Télécharger la présentation

Java 2 Platform Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related