CIS 551 / TCOM 401 Notes

1.26.2006

Access Control

      What are the security issues in mobile code (for example, a java applet)?

• Access to resources

• Confidentiality

• Installation of other software

• Crash Machine - DOS

• How do you know you trust the applet?

Java and C# Security

    Browsers enforce security in the Java virtual machine using properties of the Java Language.

    Java and C# are designed to eliminate unsafe casts and buffer overflows

• They are Static Type systems ( C is neither type nor memory safe)
• They make no direct references to memory
• All array checks in Java have bounds information

    Applets are compiled as Java bytecode

• Almost universally portable
• Bytecode contains type information

    Mobile code is susceptible to man-in-the-middle tampering

• Java allows client to runs bytecode check
• Don't have to completely trust remote machine
• Language-Level features can be enforced (save a few minor loopholes)

Applet Security Problems

    Browsers monitor applet requests for resources (network connections, files, etc.)

    Applets should have access to a minimal set of resources (a la least privilege)

Access Control For Applets

    In Unix, everything is a file, applet access involves finer levels of granularity

    Applets may need to use code with different levels of access

    How is the access control policy specified?

• Java uses a hybrid of access control lists & capabilities

Java Security Model

    Virtual Machine

• Interprets bytecode
• Uses classloaders to load the class files
• Security Manager answers access control questions (basically a a reference monitor)

    Classes can come from all over the Internet

    When a class is loaded, the security manager assigns it to a domain

    Security policy in Java assigns permissions to domains

Kinds of Permissions

    Permissions are java objects

    java.security.AllPermission is equivalent to root access

    Developers can create custom permission subclasses

    Permission classes don't directly inherit the permissions of the calling class

Code Trustworthiness

    Code origin is one way to decide what level of trust to grant

• Local vs. Remote
• Trusted domain vs. untrusted domain

    A trusted domain can digitally sign bytecode to prevent tampering

Classloader Hieracrhy

    Classloaders are java objects

    Who loads the first classloader?

•     The primordial classloader - built in for singular task of loading the source classloader class

Classloader Resolution

    Classes in virtual machine can refer to other classes

    Classloader will check security policy information

    Permissions are assigned statically

    An applet may not have access to all permissions while running

• If a remote applet could use local code to gain all permissions, it would create a security hole

Example Java Policy

    Files provide a mapping from domains to positions

    Define mappings between domains and permissions

• "grant codebase" -> write permission declarations
• "grant signed by" -> provide key, write permission declarations

    This slide example:

• Local code has all permissions
• Untrusted remote code can read and write in /tmp directory only
• Trusted remote code can read and write in /tmp and use sockets

Example Trusted Code

    Security Manager is another java class

   This slide example

• Don't want applet to be able to write to all files
• Asks for permission ahead of time with "checkPermission"
• Code can enable privileges only when it has permission

Example Client

   Slide:   Untrusted Applet makes an attempt to write to files by calling trusted "FileWrite" code. 

    Decision depends on context

• Write to /tmp/foo.txt                            - should be OK
• Write to /home/stevez/important.tex     - should fail

Stack Inspection

    In Java access depends on the runtime stack of code - every stack frame is annotated with privileges

    Look through stack for context when exercising privileges

• Enable privilege marks stack
• Check privilege initiates the walk down the stack
• Fail if unauthorized frame found
• Succeed if activated privilege is found (and no unauthorized frames)
• If neither condition is met behavior is browser dependent
  • Fail is secure
  • Succeed is insecure

Stack Inspection Example

    Stack Inspection occurs at checkPermission at the top

• Crawl down stack
• Query policy database at each frame
• Permission enabled at bottom = suceed
• Encounter no authPermission = fail

Other Possibilities

    Information Flow

    Calls to "disable privilege"

Stack Inspection Algorithm

    The "Netscape" way in the slide is more secure

    Actual implementation may have changed since the slide was created

Two Implementations

    Walking down the stack is expensive and prohibits some complier optimizations

    The alternative is to pass permissions among stack frames

Stack Inspection

    Interesting alternative to UNIX-style permissions - gets around setuid problem

    Complicated to understand instantaneous security policy

    In practice stack inspection doesn't get you some of the way to applet security

    However, lots of tradeoffs involved, and "the jury is still out"