1 / 25

JAVA Security

JAVA Security. Jdk1.0. sandBox. Ilo sistema di sicurezza JAVA si basa sulla struttura della seandBox. In base a tale politica tutte le applicazioni eseguite in locale so sicure per default, mentre gli applet sono tutte insicure (ad esempio non hanno accesso al filesystem). Jdk 1.1. Jdk1.1.

zoltan
Download Presentation

JAVA Security

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. JAVA Security

  2. Jdk1.0

  3. sandBox Ilo sistema di sicurezza JAVA si basa sulla struttura della seandBox. In base a tale politica tutte le applicazioni eseguite in locale so sicure per default, mentre gli applet sono tutte insicure (ad esempio non hanno accesso al filesystem).

  4. Jdk 1.1

  5. Jdk1.1 La jdk1.1 estende la sandBox della jdk1.0 e permette di definire sicure alcuni applet. Fornisce infatti un metodo per apporre sull’applet un a firma digitale in base alla quale riconoscere se concedere l’accesso alle risorse del sistema.

  6. Jdk1.1 e jdk1.2 • Il jdk1.1 viola però il principio del minimo privilegio: • tutti gli applet che possiedono tale firma e provengono da tale host (anche il browser deve essere configurato in modo da ritenere sicuri gli applet provenienti da un certo URL) sono considerati sicuri Il jdk1.2 permette di assegnare ad applet, firmati da diverse persone, ma provenienti dallo stesso URL, diversi gradi di accesso alle risorse.

  7. J2SE

  8. sandBox jdk1.2

  9. Fine-grained access control. • Questa caratteristica esisteva dall’inizio ma richiedeva al programmatore di specializzare delle classi (SecurityManager ed il ClassLoader classes). • Il browser HotJava 1.0 è un’applicazione che permette all’utente del browser di slezionare un piccolo numero di levelli di sicurezza. • Questo tipo di programmazione e estremamente complicato e richiede esperienza nel campo della sicurezza.

  10. Easily extensible access control structure. • Per gestire nuovi tipi di permessi occorreva con jdk1.1 estendere il security manager • Con jdk1.2 e sufficiente creare nuovi Permessi che vengono gestiti automaticamente dal sistema • Non occorre creare nuovi metodi per il security manager

  11. Extension of security checks to all Java programs • Non c’è più il presupposto che tutto il codice con codebase locale è trusted • Il codice locale (packages non di sistema istallati sul filesystem locale) viene gestito come qualunque apllet. • È possibile costruire politiche che ddanno al codice remoto gli stessi privilegi di quello locale • Gli stessi principi applicati alle applet firmate possono essere applciati alle applicazioni

  12. Execution Threads • Un thread in esecuzione invoca più classi appartenenti a domini diversi • Un dominio con un più limitato ser di permessi non può acquisirne altri chiamando o essendo chiamato da domini con maggiori privilegi

  13. Execution Threads • L’insieme di permessi concessi ad un thread è considerato l’intersezione dei permessi di tutti I domeni di protezione attraversati dal thread • Chiamando un metodo doPrivilieged() e possibile abilitare una parte di codice temporaneamente ad accedere a più di quelle direttamente concesse all’applicazione chiamante.

  14. Easily configurable security policy. Esisteva nelle prime versioni ma non era utilizzabile in maniera così semplice È preferibile scrivere file di policies che codice

  15. La norma di sicurezza Mentre nelle versioni precedenti di jdk1.0 solo il programmatore poteva implementare un SecurityManager personalizzato, con jdk1.2 è possibile stabilire una norma di sicurezza compilando un apposito fille nella cartella: jdk1.2\lib\security\java.policy

  16. Altri possibili metodi • Creando o modificando il file java.policy nella directory dell’utente • Sostituendo il valore della proprietà di sistema policy.java con il nome di un altro file contenente la nuova norma • Per aggiungere una norma di sicurezza all’esecuzione di un programma: • java –Djava.security.policy=“test.policy” Test • java –Djava.security.policy==“test.policy” Test

  17. Sintassi della norma di sicurezza Grant [SignedBy “Piero,Luisa”] [, CodeBase “URL”]{ voci permesso }; Piero e Luisa sono i firmatari, mentre l’URL è l’indirizzo da cui deve provenire l’applet da sottomettere alla norma. Es: http://www.trusted.com file:/local/applets

  18. Voci di permesso permission nome_classe_Permesso [“nome_destinatario”] [, “action_list”] [, SignedBy “nomi_firmatari”]; ES: permission java.io.FilePermission ”.”,“read,write,delete,execute”; permission java.lang.RuntimePermission “queueJob”

  19. Creare un nuovo Permesso

  20. Gestione del Permesso Policy: grant codeBase  "http://java.sun.com/" { permission com.abc.TVPermission "channel-5", "watch"; } Codice: com.abc.TVPermission tvperm = new com.abc.TVPermission("channel-5", "watch"); AccessController.checkPermission(tvperm);

  21. KeyStore E un database che consente di gestire coppie di chiavi pubblica/privata per l’autenticazione e certificati digitali. Creare un keyStore: keytool –genkey –alias “Me” –keysore “MyStore” Quindi viene richiesta una password e le seguenti informazioni:

  22. Firmare un applet • Si compili il file ReadFileApplet • Si crei un file ReadFileApplet.jar con il comando: • jar cf ReadFileAplet.jar ReadFile*.class • Si elimino ReadFileApplet.class e ReadFileApplet$ButtonHandler.class • Si esegua: • jarsigner –keystore Mystore –storepass Mypassword –keypass MyPassword ReadFileApplet.jar Me

  23. Esempio • Applet ReadFileApplet • File html

More Related