CIS 551 / TCOM 401 Notes
What are the security issues in mobile code (for example, a java applet)?
Access to resources
Installation of other software
Crash Machine - DOS
How do you know you trust the applet?
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
Applets are compiled as Java bytecode
Mobile code is susceptible to man-in-the-middle tampering
Browsers monitor applet requests for resources (network connections, files, etc.)
Applets should have access to a minimal set of resources (a la least privilege)
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?
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
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 origin is one way to decide what level of trust to grant
A trusted domain can digitally sign bytecode to prevent tampering
Classloaders are java objects
Who loads the first classloader?
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
Files provide a mapping from domains to positions
Define mappings between domains and permissions
This slide example:
Security Manager is another java class
This slide example
Slide: Untrusted Applet makes an attempt to write to files by calling trusted "FileWrite" code.
Decision depends on context
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
Stack Inspection occurs at checkPermission at the top
Calls to "disable privilege"
The "Netscape" way in the slide is more secure
Actual implementation may have changed since the slide was created
Walking down the stack is expensive and prohibits some complier optimizations
The alternative is to pass permissions among stack frames
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"