The document discusses the evolution of the Java security model from JDK 1.0 to recent versions. It started with a simple sandbox model separating trusted and untrusted code. Over time, features like applet signing, fine-grained permissions, JAAS roles and principals, and module-based security were added to enhance the security and flexibility of granting access to untrusted code. The model aims to safely execute code from various sources while preventing unauthorized access.
7. voxxeddays.com/luxembourg/ #voxxeddaysLU
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
8. voxxeddays.com/luxembourg/ #voxxeddaysLU
Evolution of the
Java security model
• 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
…
9. voxxeddays.com/luxembourg/ #voxxeddaysLU
Evolution of the
Java security model
• 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
10. voxxeddays.com/luxembourg/ #voxxeddaysLU
Evolution of the
Java security model
• JDK 1.0 (when it all started …) – the original sandbox model was
introduced
Applet
(untrusted)
System code
(trusted)
JVM
Browser
http://voxxed.com/demoapplet
11. voxxeddays.com/luxembourg/ #voxxeddaysLU
Evolution of the
Java security model
• 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
12. voxxeddays.com/luxembourg/ #voxxeddaysLU
Evolution of the
Java security model
• JDK 1.1 (gaining trust …) – applet signing introduced
Applet
(untrusted)
System code
(trusted)
JVM
Browser
Signed Applet
(trusted)
http://voxxed.com/demoapplet
http://voxxed.com/trustedapplet
14. voxxeddays.com/luxembourg/ #voxxeddaysLU
Evolution of the
Java security model
• 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
15. voxxeddays.com/luxembourg/ #voxxeddaysLU
Evolution of the
Java security model
• JDK 1.2 (gaining more trust …) – fine-grained access control
Applet
System code
JVM
Browser
grant codeBase http://voxxed.com/demoapplet {
permission java.io.FilePermisions “C:Windows” “delete”
}
security.policy
SecurityManager.checkPermission(…)
AccessController.checkPermission(…)
http://voxxed.com/demoapplet
16. voxxeddays.com/luxembourg/ #voxxeddaysLU
Evolution of the
Java security model
• The security model becomes code-centric
• Additional access control decisions are specified in a security
policy
• No more notion of trusted and untrusted code
17. voxxeddays.com/luxembourg/ #voxxeddaysLU
Evolution of the
Java security model
• The notion of protection domain introduced – determined by the
security policy
• Two types of protection domains – system and application
18. voxxeddays.com/luxembourg/ #voxxeddaysLU
Evolution of the
Java security model
• The protection domain is set during classloading and contains the
code source and the list of permissions for the class
applet.getClass().getProtectionDomain();
19. voxxeddays.com/luxembourg/ #voxxeddaysLU
Evolution of the
Java security model
• One permission can imply another permission
java.io.FilePermissions “C:Windows” “delete”
implies
java.io.FilePermissions “C:Windowssystem32” “delete”
21. voxxeddays.com/luxembourg/ #voxxeddaysLU
Evolution of the
Java security model
• 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
22. voxxeddays.com/luxembourg/ #voxxeddaysLU
Evolution of the
Java security model
• JDK 1.3, 1,4 (what about entities running the code … ?) – JAAS
Applet
System code
JVM
Browser
http://voxxed.com/demoapplet
grant principal javax.security.auth.x500.X500Principal "cn=Tom"
{ permission java.io.FilePermissions “C:Windows” “delete” }
security.policy
23. voxxeddays.com/luxembourg/ #voxxeddaysLU
Evolution of the
Java security model
• 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
24. voxxeddays.com/luxembourg/ #voxxeddaysLU
Evolution of the
Java security model
• The authentication component of JAAS is independent of the
security sandbox in Java and hence is typically used in more wider
context (such as j2ee app servers)
• The authorization component is the one that extends the Java
security policy
25. voxxeddays.com/luxembourg/ #voxxeddaysLU
Evolution of the
Java security model
• 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
26. voxxeddays.com/luxembourg/ #voxxeddaysLU
Evolution of the
Java security model
• 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(…)
27. voxxeddays.com/luxembourg/ #voxxeddaysLU
Evolution of the
Java security model
• Up to JDK 1.4 the following is a typical flow for permission
checking:
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)
28. voxxeddays.com/luxembourg/ #voxxeddaysLU
Evolution of the
Java security model
• Up to JDK 1.4 the following is a typical flow for permission
checking:
3) when system code is invoked from the remote code the SecurityManager
is used to check against the intersection of protection domains based on
the chain of threads and their call stacks
29. voxxeddays.com/luxembourg/ #voxxeddaysLU
Evolution of the
Java security model
• Up to JDK 1.4 the following is a typical flow for permission
checking:
SocketPermission permission = new
SocketPermission(“voxxed.com:8000-9000","connect,accept");
SecurityManager sm = System.getSecurityManager();
if (sm != null) sm.checkPermission(permission);
30. voxxeddays.com/luxembourg/ #voxxeddaysLU
Evolution of the
Java security model
• Up to JDK 1.4 the following is a typical flow for permission
checking:
4) application code can also do permission checking against remote code
using a SecurityManager or an AccessController
31. voxxeddays.com/luxembourg/ #voxxeddaysLU
Evolution of the
Java security model
• Up to JDK 1.4 the following is a typical flow for permission
checking:
SocketPermission permission = new
SocketPermission(“voxxed.com:8000-9000", "connect,accept");
AccessController.checkPermission(permission)
32. voxxeddays.com/luxembourg/ #voxxeddaysLU
Evolution of the
Java security model
• Up to JDK 1.4 the following is a typical flow for permission
checking:
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(…)
33. voxxeddays.com/luxembourg/ #voxxeddaysLU
Evolution of the
Java security model
• 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)
35. voxxeddays.com/luxembourg/ #voxxeddaysLU
Evolution of the
Java security model
• 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)
36. voxxeddays.com/luxembourg/ #voxxeddaysLU
Evolution of the
Java security model
• JDK 1.9 and beyond … (applying the model to modules …)
application module
system
module 1
JVM
Browser
http://voxxed.com/appmodule
security.policy
system
module 2
37. voxxeddays.com/luxembourg/ #voxxeddaysLU
Evolution of the
Java security model
• 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)
38. voxxeddays.com/luxembourg/ #voxxeddaysLU
Evolution of the
Java security model
• 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
40. voxxeddays.com/luxembourg/ #voxxeddaysLU
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 …
41. voxxeddays.com/luxembourg/ #voxxeddaysLU
Outside the sandbox:
APIs for secure coding
• 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)
42. voxxeddays.com/luxembourg/ #voxxeddaysLU
Outside the sandbox:
APIs for secure coding
• JCA provides utilities for:
• creating digital signatures
• creating message digests
• using cryptographic ciphers (symetric/asymetric, block/stream)
• using different other types of cryptographic services and algorithms
43. voxxeddays.com/luxembourg/ #voxxeddaysLU
Outside the sandbox:
APIs for secure coding
• JCA has a pluggable architecture
• JCA is independent from particular cryptographic algorithms
• JCA continues to evolve (especially by providing stronger
cryptographic algorithms)
44. voxxeddays.com/luxembourg/ #voxxeddaysLU
Outside the sandbox:
APIs for secure coding
• PKI utilities provide means for working with:
• certificates
• certificate revocation lists (CRL)
• OCSP (Online Certificate Status Protocol)
• key stores and trust stores (also based on the PKCS - public-key cryptography
standards)
45. voxxeddays.com/luxembourg/ #voxxeddaysLU
Outside the sandbox:
APIs for secure coding
• PKI certificate revocation check (revision):
• PKI utilities continue to evolve (especially in providing more
support for managing certificates and keys)
certificate authority
revocation checking
OCSP
CRL
certificate
certificate
46. voxxeddays.com/luxembourg/ #voxxeddaysLU
Outside the sandbox:
APIs for secure coding
• JSSE provides an implementation of the TSL/SSL sockets for
working with remote communication
• JSSE continues to evolve (especially in the support for additional
features such as Server Name Identication)
47. voxxeddays.com/luxembourg/ #voxxeddaysLU
Outside the sandbox:
APIs for secure coding
• Java GSS API provides an alternative of JSSE for secure communication
• Java GSS API is a framework for providing token-based security
services that is independent of the underlying protocols
48. voxxeddays.com/luxembourg/ #voxxeddaysLU
Outside the sandbox:
APIs for secure coding
• Java GSS API can be used along with JAAS for authentication purposes
• Java GSS API continues to evolve (especially in the support for
Kerberos authentication)
49. voxxeddays.com/luxembourg/ #voxxeddaysLU
Outside the sandbox:
APIs for secure coding
• Java SASL defines a protocol for exchange of authentication data
• Java SASL is a framework where external providers give concrete
semantics to the authentication data being exchanged
50. voxxeddays.com/luxembourg/ #voxxeddaysLU
Outside the sandbox:
APIs for secure coding
• Java SASL continues to evolve (especially with support for additional
and enhanced properties for exchanging authentication data)
52. voxxeddays.com/luxembourg/ #voxxeddaysLU
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 …)
53. voxxeddays.com/luxembourg/ #voxxeddaysLU
Designing and coding
with security in mind
• 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
54. voxxeddays.com/luxembourg/ #voxxeddaysLU
Designing and coding
with security in mind
• 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)
55. voxxeddays.com/luxembourg/ #voxxeddaysLU
Designing and coding
with security in mind
• 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
60. voxxeddays.com/luxembourg/ #voxxeddaysLU
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
Editor's Notes
The code source on the other hand contains the URL location, the list of signers and the list of certificates
The code source on the other hand contains the URL location, the list of signers and the list of certificates
The code source on the other hand contains the URL location, the list of signers and the list of certificates
The code source on the other hand contains the URL location, the list of signers and the list of certificates
The code source on the other hand contains the URL location, the list of signers and the list of certificates
A typical scenario – in a single multiuser operating system we may have multiple users accessing the same applet from the browser – we may want to define permissions based on the currently logged-in user by providing integration with e.g. Kerberos (in case of a Windows OS)
An AccessControlContext keeps the list of protection domains for the current thread
An AccessControlContext keeps the list of protection domains for the current thread
There are two main differences in using a SecurityManager and an AccessController:
The SecurityManager needs to be installed while AccessController only provides static methods
The SecurityManager can be customized while AccessController provides additional algorithms that can be used over the default security model
There are two main differences in using a SecurityManager and an AccessController:
The SecurityManager needs to be installed while AccessController only provides static methods
The SecurityManager can be customized while AccessController provides additional algorithms that can be used over the default security model
Calling code with a different JAAS subject is similar to the Unix setuid utility