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.

Presentazione sul tema: "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."— Transcript della presentazione:

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 La jdk1.1 estende la sandBox della jdk1.0 e permette di definire sicure alcuni applet. Fornisce infatti un metodo per apporre sullapplet un a firma digitale in base alla quale riconoscere se concedere laccesso 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 dallinizio ma richiedeva al programmatore di specializzare delle classi (SecurityManager ed il ClassLoader classes). Il browser HotJava 1.0 è unapplicazione che permette allutente 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 Linsieme di permessi concessi ad un thread è considerato lintersezione 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 allapplicazione 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 dellutente 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 allesecuzione 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 lURL è lindirizzo da cui deve provenire lapplet 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 Creare un keyStore: keytool –genkey –alias Me –keysore MyStore Quindi viene richiesta una password e le seguenti informazioni: E un database che consente di gestire coppie di chiavi pubblica/privata per lautenticazione e certificati digitali.

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 ReadFileAppletReadFileApplet File htmlhtml

24

25