Java Policy Model File - e

Java Security Model Fabrizio Pastore Università degli Studi di Milano -­‐ Bicocca Class <<load>> ClassLoader Class <<load>> ClassLoader Bootstrap Extension ClassLoader ClassLoader App ClassLoader Class Loader Types •  Nella JVM possono essere idenGficate due macro categorie di class loaders: –  Bootstrap Class Loaders –  Class Loader objects. •  Il Bootstrap Class Loader: –  è una parte essenziale della JVM –  non può essere ignorato –  Viene invocato durante il bootstrapping dell’ambiente Java e carica le classi fidate, di solito dal disco locale. •  Ci sono diversi Class Loader Objects, forniscono a Java le capacità di dynamic linking: – 
– 
– 
– 
– 
Extensions Class Loader System Class Loader Applet Class Loaders RMI Class Loaders Secure Class Loaders Security Manager Class <<use>> <<load>> ClassLoader Extension Bootstrap ClassLoader ClassLoader App ClassLoader Operazioni Svolte quando una classe viene caricata •  Controlla se la classe sia stata già caricata in precedenza –  se si, resGtuisce la classe precedentemente caricata •  Invoca il Bootstrap Class Loader –  per caricare la classe dal CLASSPATH –  questo previene il caricamento di classi che sosGtuiscono le classi fornite dalla JVM (ad esempio le classi del package java.lang) •  Verifica invocando il Security Manager che il ClassLoader abbia i permessi necessari per creare la classe –  se non li ha lancia una Security ExcepGon •  Legge il contenuto del class file e lo me[e in un array di byte –  questa operazione viene fa[a in modo diverso a seconda del class loader specifico –  class loader diversi possono caricare le classi dal filesystem locale, piu[osto che da un database o dalla rete •  Costruisce l’ogge[o che rappresenta la classe a parGre dal bytecode Operazioni Svolte quando una classe viene caricata •  Recupera le classi dire[amente riferite dalla classe appena caricata prima che questa sia usata –  include anche le classi usate dai costru[ori staGci (staGc inizializer) della classe e delle classi che estende •  Verifica la classe con il Verifier Security Manager Class <<checks>> Verifier <<use>> <<load>> <<use>> ClassLoader Extension Bootstrap ClassLoader ClassLoader App ClassLoader Verifier •  verifica suddivisa in due fasi –  controlli interni (in fase di caricamento) –  controllo a runGme (in fase di esecuzione) •  ad esempio viene verificata la corre[ezza delle operazioni di cast •  La verifica garanGsce che –  Il class file ha il corre[o formato –  gli stack (data stack, operand stack) non possono subire overflow / underflow –  Le istruzioni del Byte code instrucGons sono riferite a parametri del Gpo corre[o –  Non sono presenG conersioni di Gpo illegale –  Gli accessi ai campi Private, public, protected, e default siano legali Access Controller Class <<checks>> Security Manager Verifier <<use>> <<load>> <<use>> <<use>> ClassLoader Extension Bootstrap ClassLoader ClassLoader App ClassLoader Policy <<use>> Access Controller Class <<checks>> Security Manager Verifier <<use>> <<load>> <<use>> <<use>> ClassLoader Extension Bootstrap ClassLoader ClassLoader App ClassLoader Policy <<use>> Access Controller <<may use>> <<use>> <<may use>> Class <<checks>> Verifier <<use>> <<load>> Security Manager <<use>> ClassLoader Extension Bootstrap ClassLoader ClassLoader App ClassLoader Java Security Model •  Java gesGsce gli accessi alle risorse del sistema uGlizzando delle Policy (poliGche di sicurezza) configurabili dall’utente –  queste policy perme[o un controllo a granularità fine dell’a`vità dell’applicazione •  Quando il codice viene caricato gli vengono assegnaG dei permessi sulla base delle Policy a`ve in quel momento •  Un permesso specifica quale Gpologia di accesso il codice possa fare su una certa risorsa. –  Ad esempio: •  un permesso può indicare che il codice può leggere (assegnando il permesso “read” ) il contenuto della cartella /home/user •  un permesso può indicare che il codice può scrivere(assegnando il permesso “write” ) all’interno della cartella /tmp •  Se un permesso non è esplicitamente garanGto ad un certo codice, il codice non può accedere alla risorsa controllata da quel permesso Policy •  Un Policy serve a determinare se il codice può accedere ad una certa risorsa •  I criteri per determinarlo sono: –  codebase cioè l’URL (può indicare anche una posizione del filesystem) in cui si trovano i .class che sGamo caricando –  signer il/i firmatari, cioè lo sviluppatore che ha (eventualmente) firmato un certo jar con la firma ele[ronica –  principal il ruolo assegnato a runGme al codice in esecuzione, viene usato Gpicamente nei sistemi enterprise in cui viene effe[uato un login (non verrà visto a lezione) Security Policy File •  La/Le policy che specifica/specificano quali permessi siano garanGG al codice proveniente da una o più locazioni, piu[osto che da uno o più sviluppatori possono essere specificate dall’utente in uno o più policy file –  sono file di testo scri` con codifica ASCII –  esiste un insieme di policy di default che sono specificate nel file •  jre/lib/security/policy •  All’interno del policy file ci sono una o più entry che associano ad un insieme di elemenG codebase/signer/
principal un certo inseme di permessi –  quesG sono i permessi che vengono garanGG alle applicazioni che corrispondono al codebase/signer/principal elencaG •  Le policy entry seguono una sintassi specifica –  possono essere modificate con il comando policytool –  or usando un text editor qualsiasi Esempio di Security Policy File URL da cui viene eseguita l’applicazione grant CodeBase "h[ps://www.rstcorp.com/users/gem", SignedBy “fabrizio" { Firmatario dell’applicazione (deve corrispondere ad un nome caricato nel keystore, vedremo più avanG di cosa si tra[a) permission java.io.FilePermission "read,write", "/applets/tmp/*"; permission java.net.SocketPermission "connect", "*.rstcorp.com"; }; Permesso: l’applicazione può leggere e scrivere i file nella cartella /applets/tmp Permesso: l’applicazione può conne[ersi a tu` i server il cui hostname termina per rstcorp.com Come sono verificaG i permessi a runGme? •  Se viene richiesto l’accesso ad una risorsa prote[a –  l’intero call stack viene analizzato per verificare se l’accesso può essere consenGto •  Chi fa questo controllo? –  Il SecurityManager tramite l’AccessController Come si può scrivere del codice che impone delle verifiche su cerG permessi? •  Inserendo delle chiamate al SecurityManager SecurityManager sm = System.getSecurityManager(); != null) { if (sm P ermission perm = new java.io.FilePermission("/tmp/abc", "read"); sm.checkPermission(perm); } •  Le classi fornite con la JDK includono già le invocazioni al security manager (ad esempio nella classe FileWriter ci sono le invocazioni che controllano i permessi di scri[ura su un file) •  Il codice di una nostra applicazione conterrà chiamate ai metodi check del SecurityManager solo se la nostra applicazione implementa dei Permessi aggiunGvi –  I permessi di accesso ai file sono automa9camente controlla9 Security Manager •  implementa un set di metodi invocaG internamente dalle classi della JRE – 
– 
– 
– 
– 
checkRead(String file) checkCreateClassLoader() checkPermission(Permission perm) checkPermission(Permission perm, Object context) ... •  è possibile definire SecurityManager personalizzaG –  si suggerisce di fare l’override dei metodi check... se si intende rendere l’applicazione meno sicura –  per rendere l’applicazione più sicure è bene uGlizzare Policy personalizzate •  la JRE implementa un SecurityManager de[o DefaultSecurityManager Usare il DefaultSecurityManager •  le applicazioni java eseguite all’interno di un sistema vengono eseguite senza SecurityManager •  Il SecurityManager fornito con la JDK può essere abilitato nel seguente modo –  da console: java -­‐Djava.security.manager YourApp –  all’interno dell’applicazione code System.setSecurityManager(new SecurityManager()); •  Le applet Java eseguite nel browser sono invece eseguite da una JVM configurata con il SecurityManager Default Security Manager •  Implementa i metodi check.. ma i controlli veri e propri sono delegaG alla classe AccessController che è quella che implementa la logica di sicurezza Java –  Quando un metodo check viene eseguito il SecurityManager invoca il metodo corrispondente dell’ AccessController –  L’access controller idenGfica la Policy assegnata al codice in esecuzione –  Quindi passa alla Policy: •  l’elenco dei metodi presenG sullo stack •  il permesso richiesto (e.g. FilePermission) –  La Policy determina se l’accesso richiesto sia garanGto –  Se l’accesso non è garanGto l’AccessController lancia una java.lang.SecurityExcepGon Default Policy: Sandbox •  La JVM viene fornita con una policy di default che implementa le stesse regole implementate nel modello di sicurezza di Java 1.1 de[o Sandbox •  Queste regole fanno si che il codice eseguito nella JVM sia considerato inaffidabile (untrusted). Il codice untrusted non puà fare diverse operazioni – 
– 
– 
– 
– 
– 
– 
– 
– 
Read files Write files Delete files Rename files Create a directory List the contents of a directory Check to see whether a file exists Create a ClassLoader Create a SecurityManager Create connecGons to other computers that the host from which applet comes Default Policy: Sandbox •  Il codice Untrusted può svolgere un insieme limitato di operazioni –  access to the CPU of the client machine –  access to memory –  access to the Web server from which the applet was downloaded Esempi di Policy java.io.FilePermission(String path, String acGons) •  path è il percorso del file o della cartella per cui vogliamo garanGre all’applicazione cerG permessi di accesso –  un percorso che termina per "/*” rappresenta tu` i file e le directory contenuG nella directory rappresentata dal percorso –  un pecorso che termina per "/-­‐" rappresenta tu` i file e le cartelle contenute ricorsivamente nel percorso –  la stringa "<<ALL FILES>>" ha un valore speciale e rappresenta qualsiasi i file del sistema •  ac&ons è una stringa separata da virgole che conGene le keyword che rappresentano le azioni che vogliamo garanGre su quel percorso specifico: –  "read", "write", "execute", "delete", and "readlink” java.uGl.PropertyPermission(String name, String acGons) •  name è il nome di una proprietà di systema ("java.home", "os.name", etc). –  Un asterisco puà comparire alla fine del nome per indicare tu[e le proprietà che hanno un prefisso comune (ad esempio “user.*” corrisponde sia a “user.dir” che a “user.home”) •  ac&ons è una stringa contenente una lista di keyword separate da virgola, due sono le keyword possibili –  read perme[e al codice di invocare il metodo System.getProperty per acquisire il valore di una certa property –  write perme[e al codice di invocare il metodo System.setProperty per assegnare un valore ad un certa property Elenco di ProperGes che sono garanGte in le[ura nel Sandbox • 
• 
• 
• 
• 
• 
• 
• 
• 
• 
java.class.version java.vendor java.vendor.url java.version os.name os.arch os.version file.separator path.separator line.separator Elenco di Property che non possono essere le[e nel SandBox • 
• 
• 
• 
• 
java.class.path java.home user.dir user.home user.name Altri permessi •  java.security.AllPermission •  java.lang.reflect.ReflectPermission –  target: suppressAccessChecks •  java.security.SecurityPermission –  controlla accesso ad ogge` legaG alla gesGone della sicurezzacome Security, Policy, Provider, Signer, and IdenGty • 
• 
• 
• 
• 
javax.security.auth.AuthPermsision java.io.SerializablePermission java.net.NetPermission java.awt.AWTPermission java.lang.RunGmePermission Permessi personalizzaG •  Un’applicazione può definire il proprio set di permessi •  Ad esempio un’applicazione per la visualizzazione di canali televisivi potrebbe perme[ere la definizione di Policy che garanGscano/neghino l’accesso a canali specifici –  Definizione di una classe che estende Permission public class com.abc.TVPermission extends java.security.Permission –  All’interno dell’implementazione dell’applicazione può essere inserito un controllo sulla possibilità di accedere ad un certo canale com.abc.TVPermission tvperm = new com.abc.TVPermission("channel-­‐5", "watch"); AccessController.checkPermission(tvperm); •  Quando vengono assegnaG i protecGon domain alle classi? •  Quando una classe viene assegnata ad un ProtecGonDomain? –  Durante il caricamento –  Le slide seguenG mostrano un’animazione di quello che succede Secure ClassLoader Net ClassLoader URL App ClassLoader ClassLoader CodeSource Secure ClassLoader Class protected final Class<?> defineClass(String name, ByteBuffer b, CodeSource cs) If a non-­‐null CodeSource is supplied a ProtecGonDomain is constructed and associated with the class being defined. URL CerGficate 1..* 1 1..* 1 CodeSource Secure ClassLoader 1 protected final Class<?> defineClass(String name, ByteBuffer b, CodeSource cs) If a non-­‐null CodeSource is supplied a ProtecGonDomain is constructed and associated with the class being defined. 1 Class 1..* 0..1 ProtecGon Domain URL CerGficate 1..* 1 1..* 1 CodeSource Secure ClassLoader 1 protected final Class<?> defineClass(String name, ByteBuffer b, CodeSource cs) If a non-­‐null CodeSource is supplied a ProtecGonDomain is constructed and associated with the class being defined. 1 Class 1..* 0..1 ProtecGon Domain * 1..* Policy Permission •  Policy specifica quali permessi sono garanGG al codice che proviene da una certa code source •  CodeSource idenGfica la provenienza di una o più classi, e consiste di due elemenG: –  code locaGon (URL) –  puntatore a un cerGficato firmato (se il jar è firmato con un firma ele[ronica) •  Un Protec9onDomain rappresenta l'insieme di tu` i permessi che una certa classe può eseguire. –  racchiude •  una CodeSource •  l’insieme di permessi assegnaG al codice che proviene dalla CodeSource –  Le classi caricate da uno stesso URL e da uno stesso class loader appartengono allo stesso ProtecGonDomain •  Esiste un system domain che conGne le classi fornite con la JDK e caricate dal BootstrapClassloader Esempio: counter.Counter (1) •  se il codice è eseguito senza Security Manager il programma può leggere il contenuto del file counter_data java –Djava.security.manager counter.Counter counter_data •  quando il codice è eseguito con il Security Manager l’accesso in le[ura al file counter_data è bloccato dal security manager java –Djava.security.manager counter.Counter counter_data •  usare policytool per definire una policy –  Codebase file:/home/user/Workspaces/
workspaceJavaPolicy/ Esempio: counter.Counter (2) •  il comando policytool può esser usato per definire una policy –  Codebase file:/home/user/Workspaces/
workspaceJavaPolicy/PolicyExample/bin –  Add Permission •  FilePermission /home/user/Workspaces/ “read” –  La policy può essere salvata ad esempio nel file /
home/user/Workspaces/workspaceJavaPolicy/
PolicyExample/myPolicy Esempio: counter.Counter (3) •  l’esecuzione va a buon fine se indichiamo alla JVM il percorso (relaGvo o assoluto) del policy file con la policy da noi definita java –Djava.security.manager –Djava.security.policy=myPolicy counter.Counter counter_data •  TentaGvi di accesso a file che non appartengono a so[odirectory di /home/user/Workspaces causano il rilascio di eccezioni java –Djava.security.manager –Djava.security.policy=myPolicy counter.Counter /home/user/
myString Esempio: ProperGesReader •  Quando associamo un Security Manager l’esecuzione va a buon fine in quanto tu[e le properGes a cui la classe accede sono leggibili all’interno del sandbox java – Djava.security.manager properGes.ProperGesReader •  Se vogliamo accedere ad un altra property, ad esempio “user.dir” dobbiamo definire una policy che includa un PropertyPermission di Gpo “read” per la property “user.dir” java –Djava.security.manager –Djava.security.policy=newPolicy properGes.ProperGesReader Esempio: ProtecGonDomainPrinter •  mostra quale sia l’informazione memorizzata dalla jvm per ogni classe Esempio: Simple Applet •  Una applet Java è un’applicazione Java che può essere eseguita in un browser –  le applet sono cosGtuite da classi java (ci deve essere una classe principale che estende la classe astra[a Applet) –  le classi usate da una applet sono Gpicamente incapsulate in uno o più file jar (ma non è necessario) –  un applet viene integrata in una pagina web tramite il tag <applet> •  questo tag perme[e di passare alla applet uno o più parametri •  questo fa si che il codice della applet possa non venire modificato, mentre il suo comportamento può essere modificato a seconda dei desideri dello sviluppatore che ha implementato la pagina web –  una applet viene Gpicamente resa disponibile tramite un server remoto che ospita la pagina html con il tag applet e il bytecode della applet •  a[enzione il bytecode della applet viene eseguito LOCALMENTE •  la pagina html all’url che segue integra una java applet h[p://3d-­‐
xplormath.org/j/applets/en/vmm-­‐polyhedron-­‐Dodecahedron.html Esempio: Simple Applet •  Questo esempio mostra come la policy di default (il cosidde[o sandbox) associata all’esecuzione di applet non perme[a alcune operazioni, come ad esempio la scri[ura di un file nella home directory dell’utente •  Questo esempio invece di usare un server Web remoto uGlizza un server Web locale installato nella VirtualMachine del corso ed accedibile puntando il browser all’indirizzo h[p://localhost •  Le classi che compongono l’applet sono raggruppate in un jar file, il file può essere creato da console eseguendo il comando “make” •  Per simulare l’installazione del jar nella pagina di un sito web remoto il Makefile include un’operazione di deploy che copia i file simpleApplet.html, simpleApplet.jar nella cartella /var/www/simpleApplet –  l’operazione viene eseguita digitando su console il comando make deploy •  Per eseguire l’applet nel browser occorre inserire nella barra dell’indirizzo l’indirizzo hGp://localhost/simpleApplet/simpleApplet.html Plug-­‐in e Privilegi •  Alcuni sistemi so{ware prevedono di essere personalizzaG –  archite[ure a plug-­‐in •  Implementazione banale in SimplePluginApplicaGon –  un jar/o una cartella del classpath che include una nuova versione di UserNameDetector perme[e di personalizzare l’output dell’applicazione SimpleAppletPlugin •  Scenario, abbiamo: –  un’applicazione di cui ci fidiamo SimplePluginApplica9on –  un’estensione di cui non ci fidiamo SimplePluginApplica9on_Extension –  vorremmo usare l’estensione per personalizzare l’output ma vorremmo essere sicuri che questa si limiG a personalizzare l’output senza fare altro •  ma questo codice potrebbe fare delle cose non volute (e.g. scrivere sul filesystem), –  l’uGlizzo di un SecurityManager e di Policy che si fidano solo di SimplePluginApplicaGon blocca l’esecuzione di _Extension –  ci sono diverse situazioni in cui non vogliamo costringere l’utente a modificare le policy (si supponga che SimplePluginApplica9on siafornita dall’azienda mentre le sue estensioni non lo sono) •  soluzione PrivilegedBlocks Privileged Blocks •  Abilita del codice trusted ad accedere temporaneamente più risorse di quelle garanGte al CodeSource che lo implemente •  Esempio: –  le applicazioni web Gpicamente (applet) non possono accedere ai file che contengono i font, tu[avia un applicaGvo che visualizza i documenG potrebbe averne bisogno, quindi la JVM perme[e temporaneamente l’accesso ai file dei font(ma solo a quelli) Privileged Block: implementazione estendendo l
a c
lasse A
cGon import java.security.*; class MyAcGon implements PrivilegedAcGon<Void> { public Void run() { // Privileged code goes here, for example: System.loadLibrary("awt"); return null; // nothing to return } } import java.security.*; public class NoReturnNoExcepGon { public void somemethod() { MyAcGon mya = new MyAcGon(); // Become privileged: AccessController.doPrivileged(mya); } public staGc void main(String... args) { NoReturnNoExcepGon myApplicaGon = new NoReturnNoExcepGon(); myApplicaGon.somemethod(); } } Esempio: DummyHack •  In presenza di un securityManager non c’è modo di eseguire operazioni privilegiate se non sono in un doPrivilege block AsserGng a Subset of Privileges doPrivileged( PrivilegedAcGon<T> acGon, AccessControlContext context, Permission... perms) •  AccessControlContext. –  To perform an addiGonal security check within a different context, such as a worker thread. –  an AccessControlContext instance can be obtained from a parGcular calling context with the method AccessControlContext.getContext, and saved for future use –  If null no addiGonal security checks. •  Permission... –  varargs parameter to specify one or more Permission parameters or an array of Permission objects RiferimenG AggiunGvi •  AppunG del Corso Università del Sannio (Sez. 3 e 4) –  h[p://www.di.unisa.it/users/ads/corso-­‐security/
www/CORSO-­‐9900/java/index.htm •  Libro Securing Java –  h[p://www.securingjava.com Tutorial disponibili sul sito di Oracle •  h[p://docs.oracle.com/javase/8/docs/technotes/
guides/security/smPortGuide.html •  h[p://docs.oracle.com/javase/8/docs/technotes/
guides/security/permissions.html •  h[p://www.digicert.com/code-­‐signing/java-­‐code-­‐
signing-­‐guide.htm •  h[p://docs.oracle.com/javase/8/docs/technotes/
guides/security/permissions.html •  h[p://docs.oracle.com/javase/7/docs/technotes/
guides/security/PolicyFiles.html •  h[p://docs.oracle.com/javase/8/docs/technotes/
guides/jweb/security/manifest.html •  h[p://docs.oracle.com/javase/tutorial/deployment/
applet/deployingApplet.html