Sicurezza in Java

 Evoluzione dei modelli di sicurezza in Java

 Architettura di autorizzazione nel JDK 1.2

1
 Java Virtual Machine
Loading caricamento in memoria del file .class
Verification verifica byte-code

Linking Preparation allocazione spazio in memoria

Resolution risoluzione di tutti i riferimenti

simbolici ad altre classi

Initializing inizializzazione di tutte le variabili

statiche allocate

Esecuzione Esempio:
di main() int intero = 5
preparation: memoria per l’int
inizializing: il valore di int viene modificato in 5

2
 Il Class Loader di Java (1.)
Caratteristiche:
• “lazy” loading; le classi sono caricate “on demand" e possibilmente
all’ultimo momento

Esempio:
Prova p = new Prova();

Attrib1 a1;
classe Attrib2 a2=new Attrib2();
Prova

initAttrib1() { a1=new Attrib1(); }

• programmabilità
• creazione di namespace multipli

3
 Il Class Loader di Java (2.)

Recupero dei dati Caricamento della classe

della classe

Definizione Caricamento delle

della classe superclassi

Risoluzione Esecuzione della fase di

della classe Verification

N.B: la risoluzione può

Restituzione essere ritardata, non tutte le
della istanza di classi riferite devono essere
Class immediatamente caricate

4
Struttura della classe Class Loader

loadClass(…)

findLoadedClass(…)
Classe findSystemClass(..)
ClassLoader
findClass(…)

resolveClass()

defineClass(….)

5
class MyClassLoader extends ClassLoader {

6
 Tipi di Class Loader
• class loader interno; in JDK 1.2 usato solo per caricare le classi di Java;
•secure class loader; in JDK 1.2 permette di implementare politiche di
sicurezza più granulari;
• applet class loader; ogni browser implementa un proprio class loader;
• URL class loader; permette di caricare classi da un insieme di URL
distinte
I programmatori possono definire class loader propri purchè tutti
estendano i tipi predefiniti
Primordial CL java.lang.CL java.security.SecureCL

java.net.URLCL AppletCL

7
• Il class loader che fa il bootstrap del processo di caricamento si chiama
primordial class loader (generalmente scritto in linguaggio nativo). Il class
loader che definisce una classe si chiama defining class loader
• concetto di delega. Un class loader puo’ direttamente caricare e definire
una classe oppure delegare un altro class loader alla definizione delle classi
(ad esempio il class loader delle classi dell’applicazione puo’ delegare al
class loader interno di sistema il caricamento delle classi di sistema; questo
garantisce che tutte le classi di sistema abbiano tipi considerati unici)
=> defining and initiating class loader

A tempo di compilazione il tipo di una classe corrisponde a un nome

A runtime il tipo effettivo della classe è determinato dalla coppia nome
della classe e defining class loader: <C, L>

Due tipi di classe nell’ambiente runtime Java sono considerati uguali se i

tipi delle classi e i loro defining class loader sono uguali

8
• Istanze di MyClassLoader possono delegare il caricamento e
definizione della classe java.lang.String al class loader di sistema
• Se C è il risultato di L.defineClass() allora L è il defining class loader
• Se C è il risultato di L.loadClass allora L è il class loader che ha
avviato il processo di loading di C

Ogni classe è permanentemente associata al proprio defining class loader

ed è il defining class loader che avvia il processo di loading di
qualunque classe riferita da C

spazi di nomi separati=>occorre mantenere la consistenza tra lo spazio dei

nomi introdotto dai class loader user-defined e quello gestito dal
compilatore

La JVM mantiene la consistenza temporale dei namespace e la

consistenza dei namespace in presenza di delega

Due tipi di classe nell’ambiente runtime Java sono considerati uguali se i tipi
delle classi e i loro defining class loader sono uguali
9
Il metodo loadClass può ritornare tipi differenti per uno stesso nome di
classe in istanti di tempo diversi. Per mantenere la type safety la JVM
deve essere in grado di ottenere lo stesso tipo di classe per un dato
nome di classe e class loader

Occorre garantire che le due

occorrenze della classe X siano
dello stesso tipo per garantire la
safety della chiamata di metodo f

Approccio: la JVM non si fida che uno user-defined

loader ritorni lo stesso tipo; per garantire type safety
mantiene una cache delle classi caricate; il metodo
findLoadedClass cerca nella cache (non viene mai
invocato il metodo loadClass con lo stesso nome di
classe sullo stesso class loader più di una volta)
10
 Class Loader e Sicurezza
Il Class Loader gioca un ruolo fondamentale
• crea spazi di nomi separati;
• si coordina con il componente Security Manager che implementa le
politiche di sicurezza => associa le classi a domini di protezione

Car
www.sun.com
Class
Classi nella Virtual Machine
Class Loader L1 Car (sun.com)
Internet Car(ora.com)
Class Loader L2 L1 L2
Car Car
www.ora.com Car
Class Class
Class

11
Modello di Sicurezza in JDKTM 1.0

12
 Modello di Sicurezza in JDKTM 1.0
Vantaggi:
• la sandbox protegge l’accesso a tutte le risorse di sistema
• i programmatori di applicazioni (non di applet) possono scrivere un
proprio Security Manager per “aprire” la sandbox

Limitazioni:
• modello troppo restrittivo
• i programmatori di applicazioni (non di applet) devono scrivere un
proprio Security Manager per “aprire” la sandbox
• ad ogni politica diversa corrisponde una nuova versione del
SecurityManager

13
Modello di Sicurezza in JDKTM 1.1

14
 Modello di Sicurezza in JDKTM 1.1

Vantaggi:
• la firma del codice assicura:
– autenticazione
– integrità

Limitazioni:
• applicazioni locali non sono sottoposte ad alcun controllo
• tutte le classi presenti nel CLASSPATH sono considerate fidate

15
 Modello di Sicurezza in JDKTM 1.2
Obiettivi:
• estensione dei controlli di sicurezza sia alle applet sia alle
applicazioni (esterne e locali)
• configurabilità semplificata delle politiche di sicurezza
• controlli di accesso granulari

Elementi caratterizzanti la nuova architettura:

• politica di sicurezza
• definizione di permessi di accesso
• controllo d’accesso

16
Modello di Sicurezza in JDKTM 1.2

17
 Politica di Sicurezza (1.)
• Politica di sicurezza: matrice di controllo dell’accesso

Codice Permessi
Li Gong applet, read, write /tmp and home/gong
applet firmate

Esempio di Politica di Sicurezza (rappresentazione ASCII di default ):

grant signedBy “*”, codeBase “http://java.sun.com/people/gong/”

permission java.io.FilePermission “read, write”, “tmp/*”;

modello code-centric
Le asserzioni sono poi mantenute a run-time in un oggetto di tipo Policy

18
 Politica di Sicurezza (2.)
• CodeSource (chi/dove): località di provenienza del codice e insieme di certificati
utilizzati per la firma del codice => identifica univocamente il codice in base a
firmatari e provenienza
• Permission: permessi attribuiti al codice
• abstract class Policy:
– public static Policy getPolicy()
– public static void setPolicy(Policy policy)
– public abstract Permissions getPermissions(CodeSource cs)
– public abstract Permissions getPermissions(Subject subject, CodeSource cs)
– public abstract Permissions getPermissions(ProtectionDomain domain)
– public abstract void refresh()

19
 Secure Class Loader e Protection Domain
Protected final Class
defineClass(String name, byte [] b, int off, int len, CodeSource cs)

Il concetto di dominio di protezione introduce un livello di

indirezione che garantisce estendibilità

20
 Esempio di Secure Class Loader (1.)
public class AgentClassLoader extends SecureClassLoader
……..
public AgentClassLoader() {}
public AgentClassLoader( Environment env, String agentClass, AgentID agentID )
{ …...
codeSource = new CodeSource( AgentToURL( agentClass, agentID ),
new Certificate[0] );
}
public static URL AgentToURL( String AgentClass, AgentID agentID )
{return new URL( "http://" + agentID.place.domain +
"/" + agentID.place.place +
"/" + AgentClass +
}

21
 Esempio di Secure Class Loader (2.)
protected Class findClass(final String className) throws ClassNotFoundException
{ …..
return myFindClass( className );
}
private Class myFindClass( String className) throws Exception
{if
la classe si trova in locale then
byte [] classData= ...loadClassFile();
verifico l’autenticità delle firme sul codice
defineClass( className, classData, 0, classData.length, codeSource );
else
la cerco in remoto
…….
}

22
 Permission Class
• I permessi sono caratterizzati da:
– un type: che tipo di permessi (permessi relativi a file, a socket..);
– un target name: identifica l’oggetto a cui i permessi sono riferiti
– azioni
• 11 permessi standard Java, ognuno dei quali implementato come classe

Esempio: il FilePermission class

FilePermission p1 = new FilePermission (“-”, “execute”);
FilePermission p2 = new FilePermission (“/myclasses/*”, “read”);

Java2 introduce il concetto di aggregazione: è possibile aggregare piu’

istanze di oggetti Permission dello stesso tipo. La collezione di questo tipo è
la classe PermissionCollection
23
 Struttura della gerarchia

abstract boolean implies (Permission permission)

Checks if the specified permission's actions are "implied by" this
object's actions
Es. Permesso di leggere il file in.txt nella dir /x è implicato dal permesso
di leggere tutti i file nella dir /x 24
 Permissions Class
• Eterogenea collezione di permessi di tipologia differente

25
 Controllo dell’Accesso

JDK 1.1
SecurityManager security=System.getSecurityManager();
if (security !=null) {
Security.checkRead(“path/file”);

JDK 1.2
FilePermission perm = new
FilePermission(“path/file”,“read”);
AccessController.checkPermission (perm);

26
 Algoritmo di Controllo dell’Accesso (1.)
• L’AccessController controlla se tutti i domini nella catena delle
chiamate all’interno di un thread di esecuzione hanno il permesso
richiesto
• strategie di implementazione: eager vs. lazy evaluation

27
 Algoritmo di Controllo dell’Accesso (2.)
• quando nello stack sono presenti più domini, tutti devono avere il
permesso richiesto => least privilege principle

28
 Algoritmo Controllo Accesso
void checkPermission(Permission p) {
foreach (caller) {
if (the caller doesn’t have permission)
throw new AccessControlException(p);
if (caller is marked as privileged)
return;
}
// Access Granted
return;
}
29
 La chiamata del metodo checkPermission provoca:
• Snapshot dello stack del thread corrente e per ogni
chiamata nello stack per il dominio di protezione sullo
stack si chiama il metodo implies; tale metodo provoca la
verifica attuale dei permessi associati al quel dominio di
protezione, ossia ritrova i permessi associati al dominio di
protezione
• Se valutazione dinamica della politica si ha valutazione
dinamica dei permessi associati ad ogni dominio di
protezione; in particolare si invoca il metodo implies
dell’oggetto Policy installato sul sistema che per quel
dominio di protezione ritrova la collezioni di permessi
associati e su ognuno di essi invoca il metodo implies

30
 Caratteristiche del modello di sicurezza
di JDK 1.2
Vantaggi:
• separazione tra specifica delle politiche ed effettivo enforcement
• estensibilità e scalabilità dei controlli di sicurezza
(checkRead vs. checkPermission) => controllo dell’accesso
“tipizzato”

Limiti:
• difficoltà di controllo dell’uso delle risorse (CPU..)

31
 Riepilogando:
• Ogni pezzo di codice ha una origine (da dove proviene) ed una firma
che ne definisce l’identità
• Il comportamento di JRE e’ specificato dalla politica di sicurezza
adottata:
– Matrice di controllo di accesso che assegna permessi a codice in
esecuzione

– Internamente la politica implementata e’ rappresentata da un

oggetto che il SM puo’ consultare, instanziato dalla class
java.security.Policy

– Esternamente la politica e’ rappresentata da un file ASCII

(java.policy)

32
 The Policy reference implementation can be changed by editing the
security properties file, which is the java.security file in the lib/security
directory of the SDK.

One of the types of properties you can set in java.security is of the

following form:
policy.provider=PolicyClassName PolicyClassName must specify the
fully qualified name of the desired Policy implementation class.

The default security properties file entry for this property is the following:
policy.provider=sun.security.provider.PolicyFile

To customize, you can change the property value to specify another class,
as in
policy.provider=com.mycom.MyPolicy

33
 Politica e Permessi
Per conoscere quali permessi sono garantiti al codice, viene
consultato l’oggetto Policy:

Permissions permissions=
Policy.getPolicy().getPermissions(codesource);

34
 Permessi
Tutti i permessi devono implementare il metodo implies

Dominio di Protezione
I domini vengono costruiti a partire dal
codice e dall’insieme di permessi che si
vogliono accordare

35
Assegnare un Dominio di Protezione
• Costruire l’oggetto CodeSource
• Ottenere le Permissions dall’oggetto Policy (opzionale)
• Creare un ProtectionDomain con permessi statici o
dinamici
• Usare SecureClassLoader.defineClass per definire la classe
e associarla ad un dominio di protezione

36
 Blocchi Privilegiati
Il metodo doPrivileged() della classe AccessController
permette di ignorare i precedenti chiamanti:
void changePasswd() {
// ...normal code here
AccessController.doPrivileged(new PrivilegedAction()
{
public Object run() {
// Open file for read/write
….return null; }}); }

37
 Politiche semi-statiche vs. dinamiche

Support for dynamic policies has been added. In Java 2

SDK releases prior to version 1.4, classes were statically
bound with permissions by querying security policy during
class loading. The lifetime of this binding was scoped by
the lifetime of the class loader. In version 1.4 this binding
is now deferred until needed by a security check. The
lifetime of the binding is now scoped by the lifetime of the
security policy.

38
 Modello User-Centric
• L’utente deve essere autenticato
• Il dominio di protezione deve poter
associare al codice permessi in base non
solo al firmatario, alla provenienza ma
anche all’utente che lo sta eseguendo

39
 E i Principal?
• L’utente deve essere autenticato
• Deve essere invocato il metodo doAs della classe
Subject che crea un’associazione utente-subject,
mette in esecuzione codice che tiene traccia del
subject e crea un nuovo contesto di controllo
dell’accesso che aggiunge a quello presente sullo
stack l’informazione sui principal associati al
subject

40