Administrivia Final exam: Wed, May 12, 3:00-5:00, in this room Q&A on it today Playoffs: Fri, May...
-
date post
20-Dec-2015 -
Category
Documents
-
view
213 -
download
0
Transcript of Administrivia Final exam: Wed, May 12, 3:00-5:00, in this room Q&A on it today Playoffs: Fri, May...
Administrivia
Final exam: Wed, May 12, 3:00-5:00, in this room Q&A on it today
Playoffs: Fri, May 14, noon-2:00, FEC 141 Post-class survey (anonymous)
Notions of security What does it mean for a program to be
“secure”? Nobody can convince the program to do
“evil things” Corrupt data Release private data Elevate privileges
The program itself is not allowed to do evil things
Read files it shouldn’t Talk to hosts it shouldn’t Replicate
The role of security in Java
Java security model is 2nd case Theoretically: program can’t do evil no
user can make it do evil In practice, not so clearcut
Hard to let program do “good” things w/o also making possible “bad” things
E.g., file accesses, etc.
The sandbox mark I (Java 1.0)
Old security model: “Sandbox” “Untrusted” code (e.g., downloaded from
web) Idea: code shouldn’t be allowed to do very
risky things -- touch files, talk to network, etc. Predetermined list of risky stuff
JVM denies (exception) those accesses Good: all prog activities have to pass through
JVM all risky stuff is caught and blocked Bad: Fixed “black list”
Not granular enough for general use
Sandbox mark I
Kernel/OS API
Normal JVMSecure JVM
(appletviewer/browser)
TrustedJava Code
UntrustedJava Code
Sandbox mark I
Kernel/OS API
Normal JVMSecure JVM
(appletviewer/browser)
TrustedJava Code
UntrustedJava Code
Sandbox mark I
Kernel/OS API
Normal JVMSecure JVM
(appletviewer/browser)
TrustedJava Code
UntrustedJava Code
Sandbox mark I
Kernel/OS API
Normal JVMSecure JVM
(appletviewer/browser)
TrustedJava Code
UntrustedJava Code
Sandbox mark I
Kernel/OS API
Normal JVMSecure JVM
(appletviewer/browser)
TrustedJava Code
UntrustedJava Code
Sandbox mark I
Kernel/OS API
Normal JVMSecure JVM
(appletviewer/browser)
TrustedJava Code
UntrustedJava Code
Problems with mark I
Too coarse Disallows all file accesses Disallows all process spawning Etc.
Can’t distinguish between different users Can’t distinguish “trusted” from
“untrusted” code Can’t say “I trust code from site X, but
nobody else” or “I don’t trust code from site Y”
Sandbox revisited: security mark II
New model: security manager General Java class that decides on per-
operation basis what’s legal Configurable by host program/host JVM Can ID users & track their permissions
Also: support for “signed” applets/mobile code Cryptographic signature attached to code Use to verify sender of the code Can attach permissions to code authors
(sites) Supported in Jar file format
Sandbox mark II
Kernel/OS API
Normal JVM
(signed)Java Code
Security managerobject
Permissionsdatabase
Sandbox mark II
Kernel/OS API
Normal JVM
(signed)Java Code
Security managerobject
Permissionsdatabase
Sandbox mark II
Kernel/OS API
Normal JVM
(signed)Java Code
Security managerobject
Permissionsdatabase
Sandbox mark II
Kernel/OS API
Normal JVM
(signed)Java Code
Security managerobject
Permissionsdatabase
Sandbox mark II
Kernel/OS API
Normal JVM
(signed)Java Code
Security managerobject
Permissionsdatabase
Sandbox mark II
Kernel/OS API
Normal JVM
(signed)Java Code
Security managerobject
Permissionsdatabase
Sandbox mark II
Kernel/OS API
Normal JVM
(signed)Java Code
Security managerobject
Permissionsdatabase
Customizable security
Security database Which sites can send trusted code Which operations are allowed to specific
users Security manager object
Defined by java.lang.SecurityManager
Can sub-class to modify behavior Maybe add security checks?