M.

Joldo

SSA. ndrumtor pentru laborator

Securitatea Java 2

Securitatea n Java 2
n arhitectura de securitate Java 2, tot codul indiferent daca este rulat local sau descrcat peste reeapoate fi supus unei politici de securitate configurat de ctre utilizatorul JVM sau de ctre administrator. ntregul cod este configurat sa foloseasc un anumit domeniu (echivalent unei cutii cu nisip) i o politica de securitate care dicteaz daca codul poate fi rulat pe un anume domeniu sau nu.. Figura alturat ilustreaz arhitectura de securitate J2SE si elementele sale fundamentale. Protection Domains (domenii de protecie) ( java.security.ProtectionDomain ): n J2SE, toate aplicaiile locale ruleaz implicit fr restricii ca aplicaii de ncredere, dar pot fi configurate cu politici de control al accesului asemntoare celor definite pentru applets i aplicaii de la distan. Aceasta se realizeaz prin configurarea unui ProtectionDomain, care permite gruparea claselor i instanelor i apoi asocierea lor cu un set de permisiuni ntre resurse. Domeniile de protecie sunt catalogate n dou: "system domain" (domeniu sistem) i "application domain" (domeniu de aplicaie) Toate resursele protejate externe, cum sunt sistemele de fiiere, reelele .a.m.d. sunt accesibile doar via domenii sistem. Resursele care sunt parte a unui singur fir de execuie sunt considerate domeniu de aplicaie. Astfel, n realitate, o aplicaie care solicit acces la o resursa extern poate avea att un domeniu de aplicaie ct i un domeniu sistem. n timpul execuiei codului Jre (Java runtime environment) pstreaz o mapare de la cod la domeniul de protecie i apoi la permisiunile lui. Domeniile de protecie sunt determinate politica de securitate definita pentru JRe. Domeniile sunt caracterizate folosind un set de permisiuni asociate cu un cod surs i o locaie. Clasa java.security.ProtectionDomain ncapsuleaz caracteristicile unui domeniu protejat care cuprinde u set de clase i setul de permisiuni garantat lor la execuie de ctre utilizator. Permissions ( java.security.Permission ): n esen, permisiunile determin dac accesul la o resurs a JVM este garantat sau refuzat. Mai exact, ele dau resurselor sau claselor specificate n respectiva instan de JVM abilitatea de a permite sau refuza anumite operaii la execuie. Un applet sau o aplicaie care folosete un gestionar al securitii poate obine accesul la o resurs sistem doar dac are permisiune. Java Security API definete o ierarhie pentru clasele Permission classes, ierarhie care se pot folosi la configurarea unei politici de securitate. La rdcin, java.security.Permission este o clasa abstract care reprezint accesul la o resurs int; ea poate include un set de operaii pentru construirea accesului la o anumita resurs. Clasa Permission class conine cteva subclase care

M. Joldo

SSA. ndrumtor pentru laborator

Securitatea Java 2

reprezint accesul la diverse tipuri de resurse. Subclasele aparin unor pachete proprii lor care reprezint APIs pentru o anumita resurs. Cteva clase Permission folosite uzual sunt:

Pentru permisiuni globale (wildcard) Pentru permisiuni cu nume Pentru sistemul de fiiere Pentru reea Pentru proprieti Pentru resurse la execuie Pentru autentificare Pentru resurse grafice

-java.security.AllPermission -java.security.BasicPermission -java.io.FilePermission -java.net.SocketPermission -java.lang.PropertyPermission -java.lang.RuntimePermission -java.security.NetPermission -java.awt.AWTPermission

Codul din exemplul urmtor arat cum se protejeaz accesul la un obiect folosind permisiuni. Codul arat aplicaia apelant cu permisiunile necesare pentru a accesa obiectul.

Exemplu de folosire a permisiunilor Java pentru a proteja accesul la un obiect // Creaza obiectul care necesita protectie String protectedObj = "Doar pentru ochi de incredere"; // creaza permisiunea care va proteja obiectul. // Guard, reprezinta un obiect folosit la protectia //accesului la alt obiect an object that is used to protect Guard myGuard = new PropertyPermission ("java.home", "read"); // Creaza garda GuardedObject gobj = new GuardedObject(protectedObj, myGuard); // Obtine obtiectul gardat try { Object o = gobj.getObject(); } catch (AccessControlException e) { // Cannot access the object } Se pot defini permisiuni si folosind fiiere de configurare a politicilor (java.policy). Spre exemplu, pentru a garanta accesul n citire la un fiier (din Windows) din "c:\temp\" se poate defini FilePermission ntr-un fiier de politici de securitate (vezi exemplul urmtor)

M. Joldo

SSA. ndrumtor pentru laborator

Securitatea Java 2

Exemplu de setare a permisiunilor prin fiierul de configurare pentru politici de securitate grant{ permission java.io.FilePermission "c:\\temp\\testFile", "read"; }; Politica: Politica de securitate din Java 2 definete domenii de protecie pentru ntreg codul care ruleaz cu privilegii de acces i un set de permisiuni cum sunt citire i scriere sau realizarea de conexiuni spre o gazd. Politica pentru o aplicaie Java este reprezentat de un obiect Policy, care furnizeaz o cale de declarare a permisiunilor pentru garantarea accesului la resursele solicitate. In general, toate JVMs au mecanisme de securitate pre-construite care v permit s definii permisiuni prin intermediul unui fiier de politici de securitate Java. O JVM folosete un mecanism de control al accesului dirijat de politic prin maparea dinamic a unui set static de permisiuni definite n unul sau mai multe fiiere de configurare. Aceste intrri sunt adesea numite intrari grant . Un utilizator sau un administrator configureaz extern fiierul de politici pentru Un JRe J2SE folosind un fiier text ASCII sau un fiier binar serializat care reprezint o clas Policy. Intr-un mediu J2SE, fiierul implicit de politic pentru ntregul sistem java.policy se afl n directorul <JRE_HOME>/lib/security/ . Localizarea fiierului respectiv este definita n proprietile de securitate printr-o setare java.security, care se afl n <JRE_HOME>/lib/security/java.security. Exemplul urmtor arat un fiier de configurare de politici care specific permisiunea pentru un fiier JAR semnat ncarcat de la "http://coresecuritypatterns.com/*" i semnat de "javaguy," i apoi i garanteaz drepturi de screire/citire pentru toate fiierele din /export/home/test. Exemplu de setare a bazei pentru cod i a permisiunilor n fiierul de configurare a politicilor grant signedBy "javaguy", codebase "http://coresecuritypatterns.com/*" permission java.io.FilePermission "/export/home/test/*", "read,write"; };

Mediul J2SE furnizaez in o unealt cu interfa grafic numital "policytool" pentru editarea unui fiier de politici de securitate. Unealta se afl n "<JAVA_HOME>/bin/policytool." Implicit, JRe folosete fiierele de politici aflata n: ${java.home}/jre/lib/security/java.policy ${user.home}/.java.policy Aceste fiiere de politici sunt specificate n fiierul de securitate implicit: ${java.home}/jre/lib/security/java.security Politica efectiv a JRe va fi reuniunea tuturor permisiunilor din toate fiierele de politic. Pentru a specifica un fiier de politica suplimentar, se poate seta proprietatea sistem java.security.policy din linia de comand:

M. Joldo

SSA. ndrumtor pentru laborator

Securitatea Java 2

$ java -Djava.security.manager -Djava.security.policy=myURL MyClass Pentru a ignora politicile din fiierul java.security i a folosi doar o politic construit local folosii '==' n loc de '=': $ java -Djava.security.manager -Djava.security.policy==Mylocation/My.policy MyClass SecurityManager ( java.lang.SecurityManager ): Fiecare aplicaie Java poate avea propriul gestionar al securitii care s acioneze ca garda de securitate primar mpotriva atacurilor ru intenionate. Gestionarul securitii impune politica de securitate solicitat de o aplicaie prin realizarea de verificri la execuie i prin autorizarea accesului, protejnd astfel resursele mpotriva operaiilor ru intenionate. Intern el folosete fiierul de politici de securitate Java pentru a decide care set de permisiuni este garantat claselor. Totui, atunci cnd clase fr ncredere i aplicaii de la o a treia parte folosesc JVM, gestionarul securitii Java aplica politica de securitate asociata cu JVM pentru a identifica operaiile ru intenionate. n multe cazuri, acolo unde modelul de ameninri nu include rularea de cod ru intenionat pe JVM gestionarul securitii Java nu este necesar. In cazurile un de SecurityManager detecteaz o violare a politicilor de securitate JVM va arunca o excepie AccessControlException sau SecurityException. Intr-o aplicaie Java, gestionarul securitii este setat prin metoda setSecurityManager din clasa System. Iar gestionarul securitii curent se obine via metoda getSecurityManager (vezi exemplul urmtor). Exemplul de folosire a lui SecurityManager SecurityManager mySecurityMgr = System.getSecurityManager(); if (mySecurityMgr != null) { mySecurityMgr.checkWrite(name); } Clasa java.lang.SecurityManager const dintr-un numr de metode de genul checkXXXX cum este checkRead (String file) pentru a determina privilegiile de acces la un fiier. Metodele de verificare apeleaz metoda SecurityManager.checkPermission pentru a afla dac aplicaia apelant are permisiuni pentru a executa operaia solicitat, pe baza fiierului de politici de securitate. Daca nu, atunci arunca o SecurityException. Daca dorii ca aplicaiile s foloseasc un SecurityManager i politici de securitate, atunci lansai n execuie JVM cu optiunea -Djava.security.manager ; i putei specifica fiierul de politici cu opiunea Djava.security.policy . Dac activai gestionarul securitii Java n aplicaie, dar nu specificai un fiier de politici, atunci gestionarul securitii folosete politicile implicite definite n java.policy din directorul $JAVA_HOME/jre/lib/security. Exemplul urmtor activeaz gestionarul securitii prin program.

Exemplu de folosire a gestionarul securitii Java pentru restrngerea accesului // Inainte de activarea gestionarului securitatii, // este posibil acest apel

M. Joldo

SSA. ndrumtor pentru laborator

Securitatea Java 2

System.setProperty("java.version","Malicious: Delete"); try { // Activeaza gestionarul securitatii SecurityManager sm = new SecurityManager(); System.setSecurityManager(sm); } catch (SecurityException se) { // SecurityManager deja setat } // Dupa activarea gestionarului securitatii: // Acest apel nu mai este posibil; // se arunca o AccessControlException System.setProperty ("java.version", "Malicious: Delete"); Gestionarul securitii poate fi instalat i din inerfaa n linie de comand: $ java -Djava.security.manager <ClassName> AccessController ( java.security.AccessController ): Mecanismul controlorului accesului efectueaz o inspecie dinamic i decide daca accesul la o anumita resurs poate fi permis sau refuzat . D.p.d.v. al programatorului, controlorul accesului ncapsuleaz locaia, sursa de cod i permisiunile de efectuare a unei anumite operaii. ntr-un proces tipic, atunci cnd un program executa o operaie, el apeleaz prin gestionarul securitii care deleag cererea spre controlorul accesului i n final primete sau nu accesul la resurse. In clasa java.security.AccessController, metoda checkPermission este folosita pentru a determina dac se garanteaz sau se refuz accesul la resursa solicitat Daca se garanteaz checkPermission returneaz true; altfel, metoda arunc o excepie de accesul, tipul AccessControlException.

Exemplu de folosire a Controller pentru accesul la un director try { AccessController.checkPermission (new FilePermission("/var/temp/*", "read,write")); } catch (SecurityException e) { // Does not have permission to access the directory } Codebase: o locaie URL a unei clase sau arhive JAR se specific folosind codebase. URL se poate referi la o locaie a unui director din sistemul de fiiere local sau de pe Internet. Exemplul urmtor obine toate permisiunile garantate unei anumite clase ncrcate de la o baz de cod. Permisiunile sunt efective doar dac este instalat gestionarul securitii. Clasa ncrcat folosete acele permisiuni prin executarea Class.getProtectionDomain() i Policy.getPermissions().

Examplu de folosire a codebase URL codebase = null; try { // Obtine permisiunile pentru un URL

M. Joldo

SSA. ndrumtor pentru laborator

Securitatea Java 2

codebase = new URL("http://coresecuritypatterns.com/"); } catch (MalformedURLException e) { } catch (IOException e) { } // Construieste sursa de cod cu baza de cod CodeSource cs = new CodeSource(codebase, null); // Obtine toate permisiunile garantate PermissionCollection pcoll = Policy.getPolicy().getPermissions(cs); // Vizualizeaza fiecare permisiune din colectie Enumeration enum = pcoll.elements(); for (; enum.hasMoreElements(); ) { Permission p = (Permission)enum.nextElement(); System.out.println("Permission " + p); } Pentru a testa acest exemplu folosii fiierul de politic (test.policy), din exemplul urmtor care ofer permisiuni de citire a tuturor proprietilor sistem.

Exemplu de fiier de politic pentru testarea permisiunilor la o baz de cod grant codebase "http://coresecuritypatterns.com/-" { // Da permisiuni de citire a tuturor proprietatilor sistem permission java.util.PropertyPermission "*", "read"; }; Pentru a ignora politicile implicite din fiierul java.security file i a folosi doar politica specificat, folosii '==' n loc de '='. Folosind politica prezentat, putei rula urmatoarea comand: $ java -Djava.security.policy==test.policy TestClass CodeSource: permite reprezentarea unui URL de la care s-a ncarcat o clas i a cheilor din certificat folosite la semnarea clasei respective. Furnizeaz aceeai noiune ca i codebase, dar ncapsuleaz baza de cod (URL) a codului unde este ncrcat precum i cheile din certificat folosite la verificarea codului semnat. Clasa CodeSource i cele doua argumente ale sale folosite la specificarea locaiei codului i a cheilor asociate sunt: CodeSource(URL url, java.security.cert.Certificate certs[]); Pentru a construi o sursa de cod cu baza de cod fr a folosi certificate, se folosete: CodeSource cs = new CodeSource(codebase, null); Bytecode verifier: Verificatorul de cod Java este o parte integrant a JVM care joac un rolul important de verificare a codului nainte de execuie. Acesta asigura c codul a fost produs consistent cu specificaiile de ctre un compilator de ncredere, confirm formatul fiierului de clas i dovedete c bytecode Java este legal. Prin verificarea bytecode, codul este dovedit a fi consistent intern pe baza multiplelor reguli i constrngeri definite de compilatorul limbajului Java. Verificatorul de cod

M. Joldo

SSA. ndrumtor pentru laborator

Securitatea Java 2

poate s detecteze i inconsistene legate de anumite cazuri de verificare de limite de tablouri i de fortre de tip de obiect (object-casting) prin impunere la execuie. Pentru a controla manual nivelul verificrii bytecode n Java cu V1.2 JRE exist: -Xverify:remote ruleaz verificarea pe clase ncrcate peste reea (implicit) -Xverify:all verific toate clasele ncrcate -Xverify:none nu face verificare

ClassLoader: ClassLoader este n primul rnd responsabil de ncrcarea claselor java n JVM i apoi de conversia datelor brute ale unei clase ntr-o structur interna care reprezint clasa. D.p.d.v. al securitii ncrctoarele de clase pot fi folosite pentru stabilirea politicilor de securitate nainte de a executa cod care nu e de ncredere, pentru a verifica semnturi digitale .a.m.d.. Pentru a impune securitatea ncrctorul de clase se coordoneaz cu gestionarul securitii i controlorul accesului din JVM pentru a determina politicile de securitate ale unei aplicaii Java. ncrctorul de clase impune mai departe securitatea prin definirea separrii spaiului de nume ntre clasele ncrcate din locaii diferite, inclusiv de pe reele. Aceasta asigura c clasele ncrcate de pe mai multe gazde nu vor comunica n acelai spaiu JVM, fcnd astfel imposibil pentru codul n care nu este ncredere s obin informaii de la codul de ncredere. ncrctorul de clase afl privilegiile de acces ale aplicaiei Java folosind gestionarul securitii, care aplic politica de securitate cerut pe baza contextului aplicaiei apelate. ncepnd cu platforma Java 2 toate aplicaiile au capacitatea s ncarce clase bootstrap, clase sistem, i clase de aplicaie iniial folosind un ncrctor de clase intern (numit i ncrctor de clase primordial). Bootstrapping este procesul prin care se ncarc un program java pur foarte mic i foarte pur i fr dependine care, la ndul su, ncarc, configureaza i ruleaz prgrame mai complexe cu dependine diferite. ncrctorul de clase primordial folosete un ncrctor de clase special, SecureClassLoader, ca s protejeze JVM mpotriva ncrcrii de cod ru intenionat. Aceast clas java.security.SecureClassLoader are un constructor protejat care asociaz clasa ncrcat cu un domeniu de protecie. SecureClassLoader de asemenea folosete setul de permisiuni pentru codebase. Spre exemplu, , URLClassLoader este o subclas a SecureClassLoader. URLClassLoader permite ncrcarea clasei sau a locaiei specificate cu un URL. Exemplul urmtor arat cum se poate folosi un URLClassLoader pentru a accesa clase dintr-un director. Exemplul de folosire a URLClassLoader // Creaza un obiect File in radacina // directorului care contine fiierul clasa File file = new File("c:\\myclasses\\"); try { // Converteste File la URL URL url = file.toURL(); URL[] urls = new URL[]{url}; // Creaza un nou incarcator de clase cu directorul dat ClassLoader myclassloader = new URLClassLoader(urls); // Incarca clasa; // MyClass.class ar trebui sa se afle in // directorul file:/c:/myclasses/com/security

M. Joldo

SSA. ndrumtor pentru laborator

Securitatea Java 2

Class myclass = myclassloader.loadClass("com.security.MySecureClass"); } catch (MalformedURLException e) { } catch (ClassNotFoundException e) { } Keystore and Keytool sun descrise ntr-o lucrare dedicat uneltelor.

Mersul lucrrii
1. Studiai i executai exemplele date. 2. Concepei, documentai i realizai o modalitate de folosire a faciliottilor de securitate descrise pentru a a securiza aplicaia client-server din lucrarea anterioar.