Applications of programming language theory java security
Download
1 / 42

Applications of Programming Language Theory: Java Security - PowerPoint PPT Presentation


  • 82 Views
  • Updated On :

Applications of Programming Language Theory: Java Security. David Walker COS 441 With slides stolen from: Steve Zdancewic University of Pennsylvania. Mobile Code. Modern languages like Java and C# have been designed for Internet applications and extensible systems

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Applications of Programming Language Theory: Java Security' - luke


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Applications of programming language theory java security l.jpg

Applications of Programming Language Theory:Java Security

David Walker

COS 441

With slides stolen from:

Steve Zdancewic

University of Pennsylvania


Mobile code l.jpg
Mobile Code

  • Modern languages like Java and C# have been designed for Internet applications and extensible systems

  • PDAs, Cell Phones, Smart Cards, …

applet

applet

applet

web browser

operating system

COS 441


Applet security problems l.jpg
Applet Security Problems

  • Protect OS & other valuable resources.

  • Applets should not:

    • crash browser or OS

    • execute “rm –rf /”

    • be able to exhaust resources

  • Applets should:

    • be able to access some system resources (e.g. to display a picture)

    • be isolated from each other

  • Principles of least privilege and complete mediation apply

COS 441


Java and c security l.jpg
Java and C# Security

  • Static Type Systems (Bytecode Verification)

    • Memory safety and jump safety

    • Enforces encapsulation boundaries (e.g. private fields)

  • Run-time checks for

    • Array index bounds

    • Downcasts

    • Access controls

  • Garbage Collected

    • Eliminates memory management errors

  • Library support

    • Cryptography, authentication, …

Most of the course

This lecture

COS 441


Access control for applets l.jpg
Access Control for Applets

  • What level of granularity?

    • Applets can touch some parts of the file system but not others

    • Applets can make network connections to some locations but not others

  • Different code has different levels of trustworthiness

    • www.l33t-hax0rs.com vs. www.java.sun.com

  • Trusted code can call untrusted code

    • e.g. to ask an applet to repaint its window

  • Untrusted code can call trusted code

    • e.g. the paint routine may load a font

  • How is the access control policy specified?

COS 441


Outline l.jpg
Outline

  • Java Security Model (C# similar)

    • Stack inspection

    • Concrete examples

  • Semantics from a PL perspective

    • Formalizing stack inspection

      • how exactly does it work?

    • Reasoning about programs that use stack inspection

COS 441


Java security model l.jpg
Java Security Model

VM Runtime

Security Policy

a.class

b.class

c.class

d.class

e.class

Permissions

Domain A

Permissions

Domain B

ClassloaderSecurityManager

http://java.sun.com/j2se/1.4.2/docs/guide/security/spec/security-specTOC.fm.html

COS 441


Kinds of permissions l.jpg
Kinds of Permissions

Permissions are implemented by the java.security.Permission class for which there are many subclasses

perm = new java.io.FilePermission("/tmp/abc","read");

java.security.AllPermission

java.security.SecurityPermission

java.security.UnresolvedPermission

java.awt.AWTPermission

java.io.FilePermission

java.io.SerializablePermission

java.lang.reflect.ReflectPermission

java.lang.RuntimePermission

java.net.NetPermission

java.net.SocketPermission

COS 441


Code trustworthiness l.jpg
Code Trustworthiness

  • How does one decide what protection domain the code is in?

    • Source (e.g. local or applet)

    • Digital signatures

  • How does one decide what permissions a protection domain has?

    • Configurable – administrator file or command line

  • Enforced by the classloader

COS 441


Classloaders l.jpg
Classloaders

  • In order to pull new code into the virtual machine, we use an object from the ClassLoader class

  • A class loader will look in the file system, or across the network for a class file, or possibly dynamically generate the class

    • When loading the first class of an application, a new instance of the URLClassLoader is used.

    • When loading the first class of an applet, a new instance of the AppletClassLoader is used.

  • Class loaders are responsible for placing classes into their security domains

    • AppletClassLoader places classes in domains depending on where they are from

    • Other ClassLoaders places classes in domains based on digital signatures, or origin (such as local file system)

COS 441


Classloader hierarchy l.jpg
Classloader Hierarchy

Primordial ClassLoader

ClassLoader

SecureClassLoader

URLClassLoader

AppletClassLoader

COS 441


Associating privileges with domains l.jpg
Associating Privileges with Domains

grant codeBase “http://www.l33t-hax0rz.com/*” {

permission java.io.FilePermission(“/tmp/*”, “read,write”);

}

grant codeBase “file://$JAVA_HOME/lib/ext/*” {

permission java.security.AllPermission;

}

grant signedBy “trusted-company.com” {

permission java.net.SocketPermission(…);

permission java.io.FilePermission(“/tmp/*”, “read,write”);

}

Policy information stored in:

$JAVA_HOME/lib/security/java.policy

$USER_HOME/.java.policy

(or passed on command line)

COS 441


Summary so far l.jpg
Summary so Far

  • We’ve seen what privileges are and how to assign them to fragments of code

  • Next: how does the system use privileges to enforce an access control policy?

COS 441


Example trusted code l.jpg
Example Trusted Code

Code in the System protection domain

void fileWrite(String filename, String s) {

SecurityManager sm = System.getSecurityManager();

if (sm != null) {

FilePermission fp = new FilePermission(filename,“write”);

sm.checkPermission(fp);

/* … write s to file filename (native code) … */

} else {

throw new SecurityException();

}

}

public static void main(…) {

SecurityManager sm = System.getSecurityManager();

FilePermission fp = new FilePermission(“/tmp/*”,“write,…”);

sm.enablePrivilege(fp);

UntrustedApplet.run();

}

COS 441


Example client l.jpg
Example Client

Applet code obtained from

http://www.l33t-hax0rz.com/

class UntrustedApplet {

void run() {

...

s.FileWrite(“/tmp/foo.txt”, “Hello!”);

...

s.FileWrite(“~dpw/grades.txt”, “Nick: A+”);

...

}

}

COS 441


Stack inspection l.jpg
Stack Inspection

  • Stack frames are annotated with their protection domains and any enabled privileges.

  • During inspection, stack frames are searched from most to least recent:

    • fail if a frame belonging to someone not authorized for privilege is encountered

    • succeed if activated privilege is found in frame

COS 441


Stack inspection example l.jpg
Stack Inspection Example

Policy Database

main(…){

fp = new FilePermission(“/tmp/*”,“write,…”);

sm.enablePrivilege(fp);

UntrustedApplet.run();

}

COS 441


Stack inspection example18 l.jpg
Stack Inspection Example

Policy Database

main(…){

fp = new FilePermission(“/tmp/*”,“write,…”);

sm.enablePrivilege(fp);

UntrustedApplet.run();

}

fp

COS 441


Stack inspection example19 l.jpg
Stack Inspection Example

void run() {

s.FileWrite(“/tmp/foo.txt”, “Hello!”);

}

Policy Database

main(…){

fp = new FilePermission(“/tmp/*”,“write,…”);

sm.enablePrivilege(fp);

UntrustedApplet.run();

}

fp

COS 441


Stack inspection example20 l.jpg
Stack Inspection Example

void fileWrite(“/tmp/foo.txt”, “Hello!”) {

fp = new FilePermission(“/tmp/foo.txt”,“write”)

sm.checkPermission(fp);

/* … write s to file filename … */

void run() {

s.FileWrite(“/tmp/foo.txt”, “Hello!”);

}

Policy Database

main(…){

fp = new FilePermission(“/tmp/*”,“write,…”);

sm.enablePrivilege(fp);

UntrustedApplet.run();

}

fp

COS 441


Stack inspection example21 l.jpg
Stack Inspection Example

void fileWrite(“/tmp/foo.txt”, “Hello!”) {

fp = new FilePermission(“/tmp/foo.txt”,“write”)

sm.checkPermission(fp);

/* … write s to file filename … */

void run() {

s.FileWrite(“/tmp/foo.txt”, “Hello!”);

}

Policy Database

main(…){

fp = new FilePermission(“/tmp/*”,“write,…”);

sm.enablePrivilege(fp);

UntrustedApplet.run();

}

fp

Succeed!

COS 441


Stack inspection example22 l.jpg
Stack Inspection Example

void run() {

s.FileWrite(“~dpw/grades.txt”,

“Nick: A+”);

}

Policy Database

main(…){

fp = new FilePermission(“/tmp/*”,“write,…”);

sm.enablePrivilege(fp);

UntrustedApplet.run();

}

fp

COS 441


Stack inspection example23 l.jpg
Stack Inspection Example

void fileWrite (“~dpw/grades.txt”,“Nick: A+”) {

fp = new FilePermission(“important.txt”,

“write”);

sm.checkPermission(fp);

void run() {

s.FileWrite(“~dpw/grades.txt”,

“Nick: A+”);

}

Policy Database

Fail

main(…){

fp = new FilePermission(“/tmp/*”,“write,…”);

sm.enablePrivilege(fp);

UntrustedApplet.run();

}

fp

COS 441


Other possibilities l.jpg
Other Possibilities

  • The fileWrite method could enable the write permission itself

    • Potentially dangerous, should not base the file to write on data from the applet

  • A trusted piece of code could disable a previously granted permission

    • Terminate the stack inspection early

COS 441


Stack inspection algorithm l.jpg
Stack Inspection Algorithm

checkPermission(T) {

// loop newest to oldest stack frame

foreach stackFrame {

if (local policy forbids access to T by class executing in

stack frame) throw ForbiddenException;

if (stackFrame has enabled privilege for T)

return; // allow access

if (stackFrame has disabled privilege for T)

throw ForbiddenException;

}

// end of stack

if (Netscape || …) throw ForbiddenException;

if (MS IE4.0 || JDK 1.2 || …) return;

}

COS 441


Two implementations l.jpg
Two Implementations

  • On demand –

    • On a checkPermission invocation, actually crawl down the stack, checking on the way

    • Used in practice

  • Eagerly –

    • Keep track of the current set of available permissions during execution (security-passing style Wallach & Felten)

      + more apparent (could print current perms.)

    • more expensive (checkPermission occurs infrequently)

COS 441


Stack inspection27 l.jpg
Stack Inspection

  • Stack inspection seems appealing:

    • Fine grained, flexible, configurable policies

    • Distinguishes between code of varying degrees of trust

  • But…

    • How do we understand what the policy is?

    • Semantics tied to the operational behavior of the program (defined in terms of stacks!)

    • How do we compare implementations

    • Changing the program (e.g. optimizing it) may change the security policy

    • Policy is distributed throughout the software, and is not apparent from the program interfaces.

    • Is it any good?

COS 441


Stack inspection literature l.jpg
Stack Inspection Literature

  • Stack Inspection: Theory and VariantsCédric Fournet and Andrew D. Gordon

    • Use operational semantics like in class

  • Understanding Java Stack InspectionDan S. Wallach and Edward W. Felten

    • Formalize Java Stack Inspection using a special logic of authentication

COS 441



Abstract stack inspection l.jpg
Abstract Stack Inspection

  • Abstract permissions

    • p,q Permissions (left abstract in the theory)

    • R,S Sets of permissions (models an entity)

  • Examples:System = {fileWrite(“f1”), fileWrite(“f2”),…}Applet = {fileWrite(“f1”)}

COS 441


L sec syntax l.jpg
lsec Syntax

  • Language syntax:e ::= expressions x variablelx.e function e1 e2 application R{e} framed expr enable p in e enable test p then e1 else e2 check perm. fail failurev ::= x | lx.e valueso ::= v | fail outcomes

COS 441


Modelling the classloader l.jpg
Modelling the Classloader

  • Models the Classloader that marks the (unframed) code with its protection domain:Load(R,x) = x

    Load(R,lx.e) = lx. R{ Load(R,e) }

    Load(R,e1 e2) = Load(R,e1) Load(R,e2)

    Load(R,enable p in e)

    = enable p in Load(R,e)

    Load(R,test p then e2 else e2)

    = test p then Load(R,e1) else Load(R,e2)

    Load(R,fail) = fail

COS 441


Example l.jpg
Example

writeFile = lfileName.System{ test fileWrite(fileName) then “f2 contents” // primitive file IO

else fail

}

Applet{writeFile “f2”}-->* failSystem{writeFile “f2”}-->* “f2 contents”

COS 441


L sec operational semantics l.jpg
lsec Operational Semantics

  • Evaluation contexts:E ::= [] Hole E e Eval function v E Eval arg enable p in E Tag on stack frame R{E} Stack frame

  • E models the control stack

COS 441


L sec operational semantics35 l.jpg
lsec Operational Semantics

E[(x.e) v] --> E[e{v/x}]

E[enable p in v] --> E[v]

E[R{v}] --> E[v]

E[fail] --> fail

E[test p then e else f] --> E[e] if Stack(E) |-- p

E[test p then e else f] --> E[f] if (Stack(E) |-- p)

COS 441


Formal stack inspection l.jpg
Formal Stack Inspection

E = Applet{System{[]}}e = test fileWrite(“f2”) then “f2 contents”

else fail

When does stack(E) allow permissionfileWrite(“f2”)?

Stack(E) |-- fileWrite(“f2”)

COS 441


Formal stack inspection37 l.jpg
Formal Stack Inspection

Structure of Stacks:

s ::= . (Empty Stack)

| s.R (Stack for code of principal R)

| s.enable(p) (Privelege p enabled)

COS 441


Stack of an eval context l.jpg
Stack of an Eval. Context

Stack([]) = .

Stack(E e) = Stack(E)Stack(v E) = Stack(E)Stack(enable p in E) = enable(p).Stack(E)

Stack(R{E}) = R.Stack(E)

Stack(E’)

= Stack(Applet{System{[]}})

= Applet.Stack(System{[]})

= Applet.System.Stack([])

= Applet.System.

COS 441


Abstract stack inspection39 l.jpg

s|-- p p  R

s.R|-- p

s|-- p

s.enable(q)|-- p

s|= p

s.enable(p)|-- p

Abstract Stack Inspection

. |-- p empty stack axiom

protection domain check

p  q irrelevant enable

check enable

COS 441


Abstract stack inspection40 l.jpg

p  R

x.R|= p

x|= p

x.enable(q)|= p

Abstract Stack Inspection

. |= p empty stack enables all

enable succeeds

irrelevant enable

COS 441


What can you do with an operational semantics l.jpg
What Can You Do with an Operational Semantics?

  • Reason about optimization: Which programs are equal? (Is the optimized program the same as the unoptimized program?)

  • Eg:

    • Let C[] be an arbitrary program context.

    • Define e = e’ iff

      • for all C[], C[e] terminates whenever C[e’] terminates

COS 441


Conclusions l.jpg
Conclusions

  • What security properties does the Java security model guarantee?

  • What optimizations are legal?

  • Formal semantics helps us find the answers & suggests improvements

COS 441