Javantura v4 - Security architecture of the Java platform - Martin Toshev

Security architecture of the Java platform

Martin Toshev

@martin_fmi

Who am I

Software consultant (CoffeeCupConsulting)

BG JUG board member (http://jug.bg)

OpenJDK and Oracle RBDMS enthusiast

Twitter: @martin_fmi

http://jug.bg/

Agenda

• Evolution of the Java security model

• Outside the sandbox: APIs for secure coding

• Designing and coding with security in mind

Evolution of the Java security model


• Traditionally - companies protect they assets using strict physical and network access policies

• Tools such as anti-virus software, firewalls, IPS/IDS systems facilitate this approach


• With the introduction of various technologies for loading and executing code on the client machine from the browser (such as Applets) - a new range of concerns emerge related to client security – this is when the Java security sandbox starts to evolve …


• The goal of the Java security sandbox is to allow untrusted code from applets to be executed in a trusted environment such as the user's browser


• JDK 1.0 (when it all started …) – the original sandbox model was introduced

Applet(untrusted)

System code(trusted)

JVM

Browser

http://javantura.com/demoapplet


• Code executed by the JVM is divided in two domains – trusted and untrusted

• Strict restriction are applied by default on the security model of applets such as denial to read/write data from disk, connect to the network and so on


• JDK 1.1 (gaining trust …) – applet signing introduced

Applet(untrusted)

System code(trusted)

JVM

Browser

Signed Applet(trusted)


http://javantura.com/trustedapplet


• Local code (as in JDK 1.0) and signed applet code (as of JDK 1.1) are trusted

• Unsigned remote code (as in JDK 1.0) is not trusted


• Steps needed to sign and run an applet:• Compile the applet

• Create a JAR file for the applet

• Generate a pair of public/private keys

• Sign the applet JAR with the private key

• Export a certificate for the public key

• Import the Certificate as a Trusted Certificate

• Create the policy file

• Load and run the applet


• JDK 1.2 (gaining more trust …) – fine-grained access control

Applet

System code

JVM

Browser

grant codeBase http://javantura.com/demoapplet {permission java.io.FilePermisions “C:\\Windows” “delete”

}

security.policy

SecurityManager.checkPermission(…)AccessController.checkPermission(…)



• The security model becomes code-centric

• Additional access control decisions are specified in a security policy

• No more notion of trusted and untrusted code


• The notion of protection domain introduced – determined by the security policy

• Two types of protection domains – system and application


• The protection domain is set during classloading and contains the code source and the list of permissions for the class

applet.getClass().getProtectionDomain();


• One permission can imply another permission

java.io.FilePermissions “C:\\Windows” “delete”

implies

java.io.FilePermissions “C:\\Windows\\system32” “delete”


• One code source can imply another code sourcecodeBase http://javantura.com/

implies

codeBase http://javantura.com/demoapplet


• Since an execution thread may pass through classes loaded by different classloaders (and hence – have different protection domains) the following rule of thumb applies:

The permission set of an execution thread is considered to be the intersection of the permissions of all protection domains traversed by the execution thread


• JDK 1.3, 1,4 (what about entities running the code … ?) – JAAS

Applet

System code

JVM

Browser


grant principal javax.security.auth.x500.X500Principal "cn=Tom"

{ permission java.io.FilePermissions “C:\\Windows” “delete” }

security.policy


• JAAS (Java Authentication and Authorization Service) extends the security model with role-based permissions

• The protection domain of a class now may contain not only the code source and the permissions but a list of principals


• The authentication component of JAAS is independent of the security sandbox in Java and hence is typically used in more wider context (such as JavaEE application servers)

• The authorization component is the one that extends the Java security policy


• Core classes of JAAS:

• javax.security.auth.Subject - an authenticated subject

• java.security.Principal - identifying characteristic of a subject

• javax.security.auth.spi.LoginModule - interface for implementors of login (PAM) modules

• javax.security.auth.login.LoginContext - creates objects used for authentication


• Up to JDK 1.4 the following is a typical flow for permission checking:

1) upon system startup a security policy is set and a security manager is installed

Policy.setPolicy(…)

System.setSecurityManager(…)



2) during classloading (e.g. of a remote applet) bytecode verification is done and the protection domain is set for the current classloader (along with the code source, the set of permissions and the set of JAAS principals)



3) when system code is invoked from the remote code the SecurityManageris used to check against the intersection of protection domains based on the chain of threads and their call stacks



SocketPermission permission = new

SocketPermission(“javantura.com:8000-9000","connect,accept");

SecurityManager sm = System.getSecurityManager();

if (sm != null) sm.checkPermission(permission);



4) application code can also do permission checking against remote code using a SecurityManager or an AccessController



SocketPermission permission = new

SocketPermission(“javantura.com:8000-9000", "connect,accept");

AccessController.checkPermission(permission)



5) application code can also do permission checking with all permissions of the calling domain or a particular JAAS subject

AccessController.doPrivileged(…)

Subject.doAs(…)

Subject.doAsPrivileged(…)


• The security model defined by java.lang.SecurityManager is customizable

• For example: Oracle JVM uses a custom SecurityManager with additional permission classes where the code source is a database schema (containing e.g. Java stored procedures)


• JDK 1.5, 1.6 (enhancing the model …) – new additions to the sandbox model (e.g. LDAP support for JAAS)


• JDK 1.7, 1.8 (further enhancing the model …) – enhancements to the sandbox model (e.g. AccessController.doPrivileged() for checking against a subset of permissions)


• JDK 1.9 and beyond … (applying the model to modules …)

application module

system module 1

JVM

Browser

http://javantura.com/appmodule

security.policy

system module 2


• By modules we understand modules in JDK as defined by project Jigsaw

• Modules must conform to the same security model as applets –each module is loaded by a particular classloader (bootstrap, extension or system)


• Modularization of the JDK system classes allows further to define fine-grained access control permissions for classes in the system domain

• This is not currently allowed due to the monolithic nature of the JDK

Outside the sandbox:APIs for secure coding


• The security sandbox defines a strict model for execution of remote code in the JVM

• The other side of the coin are the security APIs that provide utilities for implementing the different aspects of application security …


• The additional set of APIs includes:• JCA (Java Cryptography Architecture)

• PKI (Public Key Infrastructure) utilities

• JSSE (Java Secure Socket Extension)

• Java GSS API (Java Generic Security Services)

• Java SASL API (Java Simple Authentication and Security Layer)

Designing and coding with security in mind


• First of all - follow programing guidelines and best practices -most are not bound to the Java programming language (input validation, error handling, type safety, access modifiers, resource cleanup, prepared SQL queries and whatever you can think of …)


• Respect the SecurityManager - design libraries so that they work in environments with installed SecurityManager

• Example: GSON library does not respect the SecurityManager and cannot be used without additional reflective permissions in some scenarios


• Grant minimal permissions to code that requires them - the principle of "least privilege"

• Copy-pasting, of course, increases the risk of security flows (if the copied code is flawed)


• Sanitize exception messages from sensitive information - often this results in an unintended exposal of exploitable information

• Let alone exception stacktraces … in many cases they convey a wealth of information about the system

Thank you

References

• Java Security Overview (white paper)

http://www.oracle.com/technetwork/java/js-white-paper-149932.pdf

• Java SE Platform Security Architecture Spec

http://docs.oracle.com/javase/7/docs/technotes/guides/security/spec/security-spec.doc.html

• Inside Java 2 Platform Security, 2nd edition

http://www.amazon.com/Inside-Java%C2%BF-Platform-Security-Implementation/dp/0201787911

http://www.oracle.com/technetwork/java/js-white-paper-149932.pdf

http://docs.oracle.com/javase/7/docs/technotes/guides/security/spec/security-spec.doc.html

http://www.amazon.com/Inside-Java%C2%BF-Platform-Security-Implementation/dp/0201787911

References

• Java Security, 2nd edition, Scott Oaks

http://shop.oreilly.com/product/9780596001575.do

• Securing Java, Gary McGraw, Ed Felden

http://www.securingjava.com

• Secure Coding Guidelines for Java SE

http://www.oracle.com/technetwork/java/seccodeguide-139067.html#0

http://shop.oreilly.com/product/9780596001575.do

http://www.securingjava.com/

http://www.oracle.com/technetwork/java/seccodeguide-139067.html#0

References

• Java 2 Network Security

http://www.amazon.com/JAVA-Network-Security-2nd-Edition/dp/0130155926

• Java Security Documentation

http://docs.oracle.com/javase/8/docs/technotes/guides/security/index.html

http://www.amazon.com/JAVA-Network-Security-2nd-Edition/dp/0130155926

http://docs.oracle.com/javase/8/docs/technotes/guides/security/index.html

References

• Core Java Security: Class Loaders, Security Managers and Encryption

http://www.informit.com/articles/article.aspx?p=1187967

• Overview of Java Security Models

http://docs.oracle.com/cd/E12839_01/core.1111/e10043/introjps.htm#CHDCEJGH

http://www.informit.com/articles/article.aspx?p=1187967

http://docs.oracle.com/cd/E12839_01/core.1111/e10043/introjps.htm#CHDCEJGH

Javantura v4 - Security architecture of the Java platform - Martin Toshev

Technology

Transcript of Javantura v4 - Security architecture of the Java platform - Martin Toshev