1 / 27

Understanding Java Security: Sandbox Model and Security Manager

This overview discusses Java's security architecture, focusing on the Sandbox Model and the enhanced Security Manager introduced in later versions. The Sandbox Model restricts untrusted code from performing potentially harmful actions, while the Security Manager entity allows for more granular control over permissions on a per-operation basis. Additionally, it explores mechanisms for dealing with signed applets and the significance of cryptographic methods in ensuring secure code execution. Understanding these principles is essential for developing secure Java applications.

kiona
Télécharger la présentation

Understanding Java Security: Sandbox Model and Security Manager

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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)

  2. The Java Security Model Playing in the sandbox...

  3. 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

  4. 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.

  5. 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

  6. Sandbox mark I Trusted Java Code Normal JVM Kernel/OS API

  7. Sandbox mark I Trusted Java Code Normal JVM Kernel/OS API

  8. Sandbox mark I Trusted Java Code Normal JVM Kernel/OS API

  9. Sandbox mark I Trusted Java Code Normal JVM Kernel/OS API

  10. Sandbox mark I Trusted Java Code Normal JVM Kernel/OS API

  11. Sandbox mark I Trusted Java Code Untrusted Java Code Normal JVM Secure JVM (appletviewer/ browser) Kernel/OS API

  12. Sandbox mark I Trusted Java Code Untrusted Java Code Normal JVM Secure JVM (appletviewer/ browser) Kernel/OS API

  13. Sandbox mark I Trusted Java Code Untrusted Java Code Normal JVM Secure JVM (appletviewer/ browser) Kernel/OS API

  14. Sandbox mark I Trusted Java Code Untrusted Java Code Normal JVM Secure JVM (appletviewer/ browser) Kernel/OS API

  15. Sandbox mark I Trusted Java Code Untrusted Java Code Normal JVM Secure JVM (appletviewer/ browser) Kernel/OS API

  16. Sandbox mark I Trusted Java Code Untrusted Java Code Normal JVM Secure JVM (appletviewer/ browser) Kernel/OS API

  17. 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”

  18. 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

  19. Sandbox mark II Permissions database (signed) Java Code Normal JVM Security manager object Kernel/OS API

  20. Sandbox mark II Permissions database (signed) Java Code Normal JVM Security manager object Kernel/OS API

  21. Sandbox mark II Permissions database (signed) Java Code Normal JVM Security manager object Kernel/OS API

  22. Sandbox mark II Permissions database (signed) Java Code Normal JVM Security manager object Kernel/OS API

  23. Sandbox mark II Permissions database (signed) Java Code Normal JVM Security manager object Kernel/OS API

  24. Sandbox mark II Permissions database (signed) Java Code Normal JVM Security manager object Kernel/OS API

  25. Sandbox mark II Permissions database (signed) Java Code Normal JVM Security manager object Kernel/OS API

  26. 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?

  27. Other Java security tools • Crypto • Public & private key • Encryption, decryption, secure hash fns • Signing, certificates • PKI (limited support) • Pluggable crypto algorithms • Policies • Generalized permission objects • Access control lists • Security databases • Customizable policy objects

More Related