4. Java goals
● Originally developed by James Gosling
● Goals:
– It should be "simple, object-oriented and familiar"
– It should be "robust and secure"
– It should be "architecture-neutral and portable"
– It should execute with "high performance"
– It should be "interpreted, threaded, and dynamic"
● JDK 1.0 : January, 1996
5. Security requirements
Safe from malevolent programs
Programs should not be allowed to harm a user's computing environment, such as
Trojan horses and harmful programs that replicate, like computer viruses.
Non−intrusive
Programs should be prevented from discovering private information on the host
computer or the host computer's network
Authenticated, Encrypted, Audited, Well-defined security specification.....
● Only the first two were within the province of Java's 1.0 default security model!
● The other requirements were added in later versions of Java
How to provide the security related requirements:
● Java Language security
● Java sandbox implementation
● Pluggable Security Extensions
6. Java Sandbox
● provide an environment where the program can play
● must be configurable by an end user or system administrator
● Protect:
– Memory
– Files
– Network
● Minimal Sandbox: program has access to the CPU, the screen, keyboard, mouse and
memory
● Default Sandbox: CPU and its own memory as well as access to the web server from
which it was loaded
● Open sandbox : the program has access to whatever resources the host machine
normally has access to
● In early versions of Java, only applets were run within a sandbox.
● In the Java 2 platform, all programs have the potential to run in a sandbox
7. Which is faster?
Java's new or C's malloc?
Response:
www.ibm.com/developerworks/java/library/j-
jtp09275/index.html
8. Anatomy of a Java application
Bytecode Verifier:Java class files follow the
rules of the Java language
Class Loader: loads all Java classes and
can set permissions for each class it loads.
Security package:
● SPI
● Message digest
● Key and certificate handling
● Digital signatures
● Encryption : JCE, JSSE
● Authentication : JAAS
Security Manager:the primary interface
between the core API and the operating system
Access Controller: allows or prevents most access
from the core API to the operating system, uses the policy files..
Debug what happens in the background: −Djava.security.debug=all/access/failure
10. Elements of a sandbox
● A sandbox is composed of five elements:
– Permissions : a specific action that code can perform
● type, name and action: permission java.io.FilePermission "/tmp/foo", "read";
● every Java class carries a set of permissions that defines the activities that the
class is allowed to perform
● core Java API are always given permission to perform any action
● application can define its own permissions
– Code sources:location from which a class has been loaded.
Combination of codebases and signers(alias listed in keystore).
– Protection domains: basic concept of sandbox, it is an association
of permissions with a particular code source
DEMO
11. Elements of a sandbox
– Policy files : contains one or more entries that define
a protection domain.
● Global policy file:$JREHOME/lib/security/java.policy
● User specific: $HOME/.java.policy
● Result: union of permissions contained in the global and user policy files
● IMPORTANT: deny setting new policy file: java.security :
policy.allowSystemProperty=true
– Keystores: The certificates themselves are held in a
location (usually a file) called the keystore.
java −Djava.security.manager −Djava.security.policy=<URL>
12. Java language security
● Question: how Java operates on things that are in memory?
● Objects, primitive types has access level: public, protected,
default/package or private
● Programs cannot access arbitrary memory locations, no pointer and
casting between int and Object is illegal.
● Entities that are declared as final must not be changed.
● Variables may not be used before they are initialized->instance variables
are initialized automatically
● Array bounds must be checked on all array accesses.
● Object serialization....Mark with java.io.Serializable, and use keyword
“transient”
● These rules must be enforced! Compiler enforcement. Is it enough???
13. Bytecode verifier
● No interface, users/coders cannot interact with it
● Checks:
– The class file has the correct format
– Final classes are not subclassed, and final methods are not overridden.
– Every class (except for java.lang.Object) has a single superclass.
– There is no illegal data conversion of primitive data types (e.g., int to Object)
– There are no operand stack overflows or underflows
● Delayed bytecode verification
● Runtime verification:array bounds checking, object casting
14. Class loaders
● mechanism by which files are read into the JVM and
converted into class definitions
● Responsibility:
– The security manager is consulted to see if this
program is allowed to access the class in question
– Loads the class
– The security manager is consulted to see if this program
is allowed to create the class in question
– The appropriate protection domain is created for the class
15. Java Security Manager
● determines whether many particular operations
should be permitted or rejected
● −Djava.security.manager option installs a security
manager
● Partnership between the Ja5va API and the
application
● The SecurityException class is a subclass of the
RuntimeException
public FileInputStream(String name) throws FileNotFoundException {
SecurityManager security = System.getSecurityManager( );
if (security != null) {
security.checkRead(name);
}
try {
open(name); // open( ) is a private method of this class
} catch (IOException e) {
throw new FileNotFoundException(name);
} }
16. Access Controller
● Security Manager is based entirely on access controller
● Uses the policy file; is built on permissions, protection
domains, code sources and policies
● the access controller can do everything the security
manager can do; historic reasons
● the access controller is only available in Java 1.2
● Applications always interact with the SecurityManager
17. JAAS
● Java Authentication and Authorization Service
● enforce access controls based on who runs
the code(policy files: where code came from)
● Features:
– Single sign-on support
– Pure Java
– Pluggable Authentication Module framework fir
authentication
18. JCE
● Java Cryptographic Extension
● Features:
– Support for a wide range of standard algorithms
including RSA, DSA, AES, Triple DES, SHA,
PKCS#5, RC2, and RC4.
– Comprehensive API with support for a wide range of
cryptographic services including digital signatures,
message digests, ciphers (symmetric, asymmetric,
stream & block), message authentication codes, key
generators and key factories
19. JSSE
● Java Secure Socket Extension
● APIs and implementations for :
– Transport Layer Security (TLS),
– Secure Sockets Layer (SSL),
– Kerberos (accessible through GSS-API) and
– full support for HTTPS over SSL/TLS.
