Maharaja Agrasen Institute of Technology

CIC-212
Java Programming

Lecture 5

Java Security Models, sandbox

model
 Java Security
Models

the need for Java security

the sandbox (Java 1.0)
the concept of trusted code (Java 1.1)
fine grained access control (Java 2)

2
 The need for Java
Security
code mobility can be useful (though not indispensable)
may reduce bandwidth requirements
improve functionality of web services

but downloaded executable content is dangerous

the source may be unknown hence untrusted
hostile applets may modify or destroy data in your file system
hostile applets may read private data from your file system
hostile applets may install other hostile code on your system
(e.g., virus, back-door, keyboard sniffer, …)
hostile applets may try to attack someone else from your system
(making you appear as the responsible for the attack)
hostile applets may use (up) the resources of your system (DoS)
all this may happen without you knowing about it
3
 The Sandbox
Model
idea: Limit the resources that can be accessed by applets
JVM

sandbox
local code
remote code
(applets)

resources
introduced in Java 1.0
local code had unrestricted access to resources
downloaded code (applet) was restricted to the sandbox
cannot access the local file system
cannot access system resources,
can establish a network connection only with its originating web server
4
 The concept of trusted
code
idea: Applets that originate from a trusted source could be trusted
JVM

local code
sandbox
signed and
trusted
remote code
(applets) unsigned, or
signed and
untrusted

resources

introduced in Java 1.1

applets could be digitally signed
unsigned applets and applets signed by an untrusted principal were
restricted to the sandbox
local applications and applets signed by a trusted principal had
unrestricted access to resources 5
 Fine grained access
control
idea: every code (remote or local) has access to the system resources based on
what is defined in a policy file

JVM

local or remote code

class loaders
(signed or unsigned)

policy
file
resources

introduced in Java 2
a protection domain is an association of a code source and the permissions
granted
the code source consists of a URL and an optional signature
permissions granted to a code source are specified in the policy file
grant CodeBase “http://java.sun.com”, SignedBy “Sun” {
permission java.io.FilePermission “${user.home}${/}*”, “read, write” 6

permission java.net.SocketPermission “localhost:1024-”, “listen”;};

The three pillars of Java
security
the Security Manager
class loaders
the bytecode verifier

7
 The Security
Manager
ensures that the permissions specified in the policy file are
not overridden
implements a checkPermission() method, which
takes a permission object as parameter, and
returns a yes or a no (based on the code source and the permissions granted
for that code source in the policy file)
checkPermission() is called from trusted system classes
e.g., if you want to open a socket you need to create a Socket object
the Socket class is a trusted system class that always invokes the
checkPermission() method
this requires thaat
all system resources are accessible only via trusted system classes
trusted system classes cannot be overwritten (ensured by the class loading
mechanism)

8
 The Security
Manager
the JVM allows only one SM to be active at a time
there is a default SM provided by the JDK
Java programs (applications, applets, beans, …) can replace the
default SM by their own SM only if they have permission to do so
two permissions are needed:
create an instance of SecurityManager
set an SM instance as active
example:
grant CodeBase “…”, SignedBy “…” {
permission java.lang.RuntimePermission “createSecurityManager”;
permission java.lang.RuntimePermission “setSecurityManager”;};

invoking the SecurityManager constructor or the setSecurityManager()

method will call the checkPermissions() method of the current SM and
verify if the caller has the needed permissions

9
 Class
loaders
separate name spaces
classes loaded by a class loader instance belong to the same name space
since classes with the same name may exist on different Web sites, different
Web sites are handled by different instances of the applet class loader
a class in one name space cannot access a class in another name space
classes from different Web sites cannot access each other
establish the protection domain (set of permissions) for a loaded
class
enforce a search order that prevents trusted system classes from
being replaced by classes from less trusted sources
see next two slide …

10
 Class loading
process
when a class is referenced
JVM: invokes the class loader associated with the requesting
program
class loader: has the class already been loaded?
yes:
does the program have permission to access the class?
yes: return object reference
no: security exception
no:
does the program have permission to create the requested class?
yes:
first delegate loading task to parent
if parent returns success, then return (class is loaded)
if parent returned failure, then load class and return
no: security exception
11
Class loading task
delegation
primordial
primordialclass
classloader
loader 4a loads class from
(searches on
(searches on
the boot class path
theboot
bootclass
classpath)
path)

3 4b failure

aaclass
classloader
loaderinstance
instance
started
started at JVMstartup
at JVM startup 5a loads class from
(searches
(searchesonon class path
the
theclass
classpath)
path)

2 5b success / failure

aaclass
classloader
loaderinstance
instance
associated 6
associated withaaURL
with URL loads class from URL
(searches on the site
(searches on the site
specified
specifiedby
bythe
theURL)
URL)
1
class request

12
 Byte code
verifier
performs static analysis of the bytecode
syntactic analysis
all arguments to flow control instructions must cause branches to the
start of a valid instruction
all references to local variables must be legal
all references to the constant pool must be to an entry of appropriate
type
all opcodes must have the correct number of arguments
exception handlers must start at the beginning of a valid instruction
data flow analysis
attempts to reconstruct the behavior of the code at run time without
actually running the code
keeps track only of types not the actual values in the stack and in local
variables
it is theoretically impossible to identify all problems that may
occur at run time with static analysis
13