Current Techniques in Language-based Security
Steve Zdancewic  U. Penn

Mobile Code
 - Based on language like Java, C#
 - Used on PDA, Cells, Smart Cards
 - Run on web browser as plug-ins

 Problems
 - protect OS & other valuable resources
 - should not
     crash broswer or OS
     play around file system
     exhaust resources
 - should
     access some system resources
     isolate from each other
 - principles
     - least privileges
     - complete mediation

Java and C# security
 - Static Type (memory and jump safety)
 - Run-time check (array index bound, downcast, access control)
 - VM / JIT compilation
     bytecode verification
     enforces encapsulation boundaries, e.g. private field
 - Garbage Collected (elliminate memory management errors)
 - Library support (cryptography, authentication, etc)

Access Control
 - what level of granularity? (which part of filesystem, runtime
   system, what objects, network connections, etc?)
 - different levels of trustworthiness for different code.
   (www.hacker.com vs. www.java.sun.com)
 - trusted code can call untrusted code
   (browser asks an applet to repaint its window)
 - untrusted code can call trusted code
   (the paint routine may load a font)
 - how is access control policy specified?

Outline
 - Jave Security Model 
   (http://java.sun.com/j2se/1.4.2/docs/guide/security/spec/security-specTOC.fm.html)
      VM Runtime                  Security Policy 
        a.class
	b.class       X      Domain A(hacker.org) ---> Permissions
	c.class       X      Domain B(sun.com) ---> Permissions
      ClassLoader
      SecurityManager

   e.g.
     java.security.Permission Class
     perm = new java.io.FilePermission( "/tmp/abc", "read" );

   Code Turstworthiness
   -- how does one decide what protection domain the code is in?
      - source
      - digital signature
      - C# calls this "evidence based"
   -- how does one decide what permissions a protection domain has?
      - configurable (admin file or command line)
   -- enforced by the classloader

   ClassLoader Hierarchy
     Primordial ClassLoader
       - ClassLoader
  	 -- SecureClassLoader
  	 -- URLClassLoader
  	      - AppletClassLoader

   ClassLoader Resolution
     When loading the first class and an app:
       a new instance of URLClassLoader is used
     When loading the first class of an applet:
       a new instance of AppletClassLoader is used
     When .ForName is directly called, the primordial class
     loader is used.
     If the request to load a class is triggered by a refrence
     from an existing class that class loader will be used
     Exceptions:
       Web browsers may reuse class loaders

   Java Policy
     grant codeBase "http://$JAVA_HOME/lib/ext/*" {
       permission java.security.AllPermission;
     }
     grant codeBase "http://www.hacker.com/*" {
       persmission java.io.FilePermission("/tmp/*", "read, write"); 
     }
     Policy information stored in
       $JAVA_HOME/lib/security/java.policy
       $USER_HOME/.java.policy

   Example Trusted Code (in system protection domain)
     void fileWrite( String filename, String s ) {
       SeucrityManager sm = System.getSecurityManager();
       if ( sm != null ) {
         FilePermission fp = new FilePermission( filename, "write" );
	 sm.checkPermission( fp );  /* it does stack inspection */
	 /* ... write s to file filename (native code on host) ... */
       } else {
         throw new SecurityException(); 
       }
     }
     
     public static void main(...) {
       SecurityManger sm = System.getSeucrityManger();
       FilePermission fp = new FilePersmission( "/tmp/*", "write,...");
       sm.enablePrivilege( fp );
       UntrustedApplet.run();
     }

     class UntrustedApplet { /* downloaded from www.hakcer.org */
       void run() {
         ...
	 s.FileWrite( "/tmp/foo.txt", "hello!" );	/* allowed */
	 ...
	 s.FileWrite( "/home/stevez/important.tex", "kwijibo" ); /* denied */
	 ...
       } 
     }

 - Stack Inspection (provides fine-grained control)
   -- stack frames are annotated with their protection domains and any 
      enabled privildges
   -- 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 

   e.g.
					
     fileWrite() {			
       fp = newFilePermission         ------->	Policy Database
       sm.checkPermission   -----
       ...                      |
     }                          |
	     ^                  |
	     |                  |
     run() {                    |    
       ...                      V 
       FileWrite();                  <------> (if not granted fail here)
       ...                  -----	      (if granted, go on checking)
     }                          |
	     ^                  |
	     |                  |
     main() {                   |
       ...                      V
       ...      	fp	fp (SUCCESS)
       ...
     }

   * a trusted code might disable stack inpsection by puting a negative tag 
     at the stack frame.

   Implementation
    - On demand
      On invocation, crawl down the stack and checking on the way (in practice)

    - Eagerly
      keep track of current set of avilable permission during execution
      more apparent as it could print current perms
      but more expensie as 'checkPermission()' occurs infrequently

   Problem:
     - how do we understand what the policy is?
     - semantics defined in terms of stacks
     - how do we compare implementation
     - changing program may chang the security policy
     - policy is distributed throughout the s/w, not apparent from program
       interface
     Analysis: 
     - A systematic Approach to Static Access Control (Francois et. al)
     - Stack Inspection: Thoery and Variants (Cedric et. al)
     - Understanding java Stack Inspection (Dan et al)

 - Semeantics from a PL perspective
   -- formalizing stack inspection
   -- Reasoning about programs that use stack inspection
   -- Type systems for stack inspection

 - Discussion & Related work
   -- relate stack inspection to information flow

