The document summarizes the evolution of the Java security model from JDK 1.0 to the present. It discusses how the security model started with a sandbox that divided code into trusted and untrusted domains. It evolved to support signed applets, fine-grained access control using security policies, and role-based access with JAAS. More recent updates applied the security model to modules. The document also discusses APIs for secure coding outside the sandbox, like JCA, PKI, JSSE, and following best practices like least privilege.
2. Advanced Java Day
BG JUG mailing list:
https://groups.google.com/foru
m/#!forum/bg-jug
3. Advanced Java DayAdvanced Java Day
Agenda
• Evolution of the Java security model
• Outside the sandbox - APIs for secure
coding
• Designing and coding with security in mind
5. Advanced Java DayAdvanced Java Day
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
6. Advanced Java DayAdvanced Java Day
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 …
7. Advanced Java DayAdvanced Java Day
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
8. Advanced Java DayAdvanced Java Day
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://javaday.bg/demoapplet
9. Advanced Java DayAdvanced Java Day
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
10. Advanced Java DayAdvanced Java Day
Evolution of the
Java security model
• JDK 1.1 (gaining trust …) – applet signing
introduced
Applet
(untrusted)
System code
(trusted)
JVM
Browser
http://javaday.bg/demoapplet
Signed Applet
(trusted)
http://javaday.bg/trustedapplet
11. Advanced Java DayAdvanced Java Day
Evolution of the
Java security model
• Trusted local code and untrusted
remote code from applets restricted to
a predefined set of operations OR
signed applet code that is trusted
12. Advanced Java DayAdvanced Java Day
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
13. Advanced Java DayAdvanced Java Day
Evolution of the
Java security model
• JDK 1.2 (gaining more trust …) – fine-
grained access control
Applet
System code
JVM
Browser
http://javaday.bg/demoapplet
grant codeBase http://javaday.bg/demoapplet {
permission java.io.FilePermissions “C:Windows” “delete”
}
security.policy
SecurityManager.checkPermission(…)
AccessController.checkPermission(…)
14. Advanced Java DayAdvanced Java Day
Evolution of the
Java security model
• Since the security model is code-centric -
additional access control decisions are
specified in a security policy
• No more notion of trusted and untrusted
code
15. Advanced Java DayAdvanced Java Day
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
16. Advanced Java DayAdvanced Java Day
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();
17. Advanced Java DayAdvanced Java Day
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”
18. Advanced Java DayAdvanced Java Day
Evolution of the
Java security model
• One code source can imply another code
source
codeBase http://javaday.bg/
implies
codeBase http://javaday.bg/demoapplet
19. Advanced Java DayAdvanced Java Day
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
20. Advanced Java DayAdvanced Java Day
Evolution of the
Java security model
• JDK 1.3, 1,4 (what about entities running
the code … ?) – JAAS
Applet
System code
JVM
Browser
http://javaday.bg/demoapplet
grant principal javax.security.auth.x500.X500Principal "cn=Tom"
{ permission java.io.FilePermissions “C:Windows” “delete” }
security.policy
21. Advanced Java DayAdvanced Java Day
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
22. Advanced Java DayAdvanced Java Day
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
23. Advanced Java DayAdvanced Java Day
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
24. Advanced Java DayAdvanced Java Day
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(…)
25. Advanced Java DayAdvanced Java Day
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)
26. Advanced Java DayAdvanced Java Day
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
27. Advanced Java DayAdvanced Java Day
Evolution of the
Java security model
• Up to JDK 1.4 the following is a typical
flow for permission checking:
SocketPermission permission = new
SocketPermission("javaday.bg:8000-
9000","connect,accept");
SecurityManager sm = System.getSecurityManager();
if (sm != null) sm.checkPermission(permission);
28. Advanced Java DayAdvanced Java Day
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
29. Advanced Java DayAdvanced Java Day
Evolution of the
Java security model
• Up to JDK 1.4 the following is a typical
flow for permission checking:
SocketPermission permission = new
SocketPermission("javaday.bg:8000-9000",
"connect,accept");
AccessController.checkPermission(permission)
30. Advanced Java DayAdvanced Java Day
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(…)
31. Advanced Java DayAdvanced Java Day
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)
32. Advanced Java DayAdvanced Java Day
Evolution of the
Java security model
• JDK 1.5, 1.6 (enhancing the model …) –
new additions to the sandbox model (e.g.
LDAP support for JAAS)
33. Advanced Java DayAdvanced Java Day
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)
34. Advanced Java DayAdvanced Java Day
Evolution of the
Java security model
• JDK 1.9 and beyond … (applying the
model to modules …)
application module
system
module 1
JVM
Browser
http://javaday.bg/appmodule
security.policy
system
module 2
35. Advanced Java DayAdvanced Java Day
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 – moreover each module is
loaded by a different classloader – hence
classes in different modules must have
different protection domains
36. Advanced Java DayAdvanced Java Day
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
38. Advanced Java DayAdvanced Java Day
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
…
39. Advanced Java DayAdvanced Java Day
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)
40. Advanced Java DayAdvanced Java Day
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
41. Advanced Java DayAdvanced Java Day
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)
42. Advanced Java DayAdvanced Java Day
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)
43. Advanced Java DayAdvanced Java Day
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
authorityrevocation
checking
OCSP
CRL
certificate
certificate
44. Advanced Java DayAdvanced Java Day
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)
45. Advanced Java DayAdvanced Java Day
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
46. Advanced Java DayAdvanced Java Day
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)
47. Advanced Java DayAdvanced Java Day
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
48. Advanced Java DayAdvanced Java Day
Outside the sandbox - APIs for
secure coding
• Java SASL continues to evolve (especially
with support for additional and enhanced
properties for exchanging authentication
data)
50. Advanced Java DayAdvanced Java Day
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 …)
51. Advanced Java DayAdvanced Java Day
Designing and coding
with security in mind
• Respect the SecurityManager -
designlibraries 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
52. Advanced Java DayAdvanced Java Day
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)
53. Advanced Java DayAdvanced Java Day
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
58. Advanced Java DayAdvanced Java Day
References
• Core Java Security: Class Loaders, Security
Managers and Encryption
http://www.informit.com/articles/article.aspx?p=118796
7
• Overview of Java Security Models
http://docs.oracle.com/cd/E12839_01/core.1111/e1004
3/introjps.htm#CHDCEJGH
Notes de l'éditeur
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