Introduzione

La seguente guida descrive sinteticamente l'architettura del sistema di sicurezza di SOMA, da ora in poi indicato con l'acronimo S.S.S. (Soma Security System), e fornisce una guida alla configurazione di esso.

SOMA (Secure Open Mobile Agents) è l'infrastruttura per Agenti Mobili sviluppata dall'università di Bologna; per avere maggiori informazioni su questo progetto si rimanda a http://www.lia.deis.unibo.it/Research/SOMA/ .

Implementare un meccanismo di sicurezza per un sistema ad Agenti Mobili pone problemi di diversa natura sintetizzabili nei seguenti punti:

  1. è necessario proteggere l'agente da ambienti di esecuzione potenzialmente ostili

  2. è necessario proteggere l'ambiente di esecuzione da agenti potenzialmente ostili

  3. l'interazione con il sistema deve essere regolato

Vista l'intrinseca complessità del problema è scaturito un sistema molto complesso, la cui gestione presuppone la conoscenza dell'architettura e di un insieme di strumenti (server ldap, PKI, ..); da questo la necessità della presente guida la cui lettura è fortemente consigliata.


Caratteristiche del S.S.S.


role based policies

Il Soma Security System permette di imporre una generica politica di sicurezza attraverso un paradigma basato sui ruoli. Questo significa che l'insieme dei permessi non viene legato ad un particolare utente, ma viene legato ad un ruolo; gli utenti sono poi legati ad uno o più ruoli e le azioni da esso compiute vengono gestite nel dominio di sicurezza del ruolo dall'utente ricoperto. 
In più i ruoli sono definiti in gerarchie, e i permessi accordati ai ruoli gerarchicamente inferiori vengono ereditati dai ruoli gerarchicamante superiori.

JAVA

L'intero sistema SOMA è sviluppato in JAVA! Questo ha permesso di utilizzare i sofisticati e robusti meccanismi di sicurezza che JAVA offre. 
In particolare si è utilizzato il sistema di sicurezza offerto dal JDK 1.2 e in più si è fatto largo uso del sistema JAAS (Java Authentication and Authorization Service)

PKI Entrust

L'autenticazione degli utenti avviente attraverso l'uso di certificati digitali il cui ciclo di vita è gestito dalla PKI Entrust. I certificati vengono utilizzati anche per altri scopi come indicato dai punti successivi.

L'ambiente di esecuzione è protetto

Gli agenti possono interagire con il sistema attraverso un insieme di API progettato per garantire che un agente ostile non possa danneggiare il sistema.

Gli agenti sono protetti

L'integrità degli agenti è assicurato attraverso l'uso di certificati digitali.

E' assicurata la non ripudiabilità delle azioni

Gli agenti sono firmati digitalmente dall'utente che li ha lanciati. E' così sempre possibile risalire al responsabile di una determinata azione.

Interazione con SOMA

Il sistema di sicurezza impone agli agenti una politicha di sicurezza in funzione del ruolo di chi li ha lanciati; ma non si limita a questo. Un generico utente interagisce con SOMA potendo utilizzare, in generale, solo un sottoinsieme dei comandi possibili. L'insieme dei comandi ammessi per un ruolo viene specificato in modo coerente al modo in cui vengono accordati tutti gli altri permessi.

Alte performances

Il S.S.S. è molto efficiente! Per assicurare la scalabilità si fa largo ricorso, come in tutto il sistema SOMA, alla definizione di località.


Architettura del S.S.S.

La seguente figura mostra un security domain e le entità che lo definiscono.

La figura mostra il caso in cui un security domain contiene tre SOMA domains e alcuni places. Sono anche indicati il server ldap e la PKI.  Il server ldap è forse il sottosistema più importante dal punto di vista dell'amministratore. Esso infatti è responsabile di mantenere le seguenti informazioni:

In più il server ldap definisce il security domain; infatti ogni istanza di SOMA viene lanciata indicando la URL del server ldap il quale è in corrispondenza 1:1 con i security domains; così affinchè un SOMA domain appartenga ad un security domain è necessario e sufficiente che l'infrastruttura SOMA che lo definisce faccia riferimento al server ldap corrispondente.


Politiche

Nel S.S.S. la politica di sicurezza è qualcosa di più di un elenco di permessi associati ad utenti. E' necessario definire una struttura dati che definisca l'insieme delle informazioni necessarie al sistema. Le seguente figura mostra schematicamente come è strutturata l'informazione:

La figura mostra lo schema del Directory Information Tree. I quadrati rappresentano classi di oggetti mentre i cerchi rappresentano un esempio di possibili istanze. In particolare le istanze delle classi roles e users sono singleton, nel senso che esiste in ogni directory una sola istanza di esse.

Come è possibile osservare, esiste un dominio fittizio denominato "default". Per comprendere il motivo di ciò, è necessario chiarire come viene gestita l'interazione con il sistema. Tipicamente una sessione di SOMA si presenta all'utente con diverse finestre. Tra queste ci sono quelle legate ai domini e ai places, ma ci sono anche alcune finestre che non sono legate ad una particolare località; per esempio la finestra di configurazione avanzata.
Durante l'interazione con finestre collegate ad una particolare località L, i comandi impartiti dall'utente vengono, prima di essere messi in esecuzione,  controllati, nel senso che viene consultata la politica attiva nella località L per assicurarsi che il ruolo attivo ha il permesso di compiere l'azione corrispondente. Ovviamente nel caso in cui il controllo non va a buon esito il comando non viene messo in esecuzione.
Durante l'interazione con finestre non collegate ad una particolare località tutto avviene come prima, con l'unica differenza che la politica che viene consultata è quella collegata al dominio fittizio "default".

Ogni oggetto è caratterizzato da attributi che sono elencati nella seguente tabella:
 

ROLE

role

identificatore del ruolo

description

descrizione del ruolo

java_class

classe java che definisce il ruolo

DC

certificato digitale di ruolo

ROLES

serial_number

è il numero seriale della politica. E' utilizzato dal meccanismo di cache e deve essere cambiato ogni volta che viene modificata la politica per forzare un aggiornamento

id

è l'identificatore del singleton

USER

cn

common name dell'utente

sn

nome completo dell'utente (opzionale)

entrust_dn

è il DN incapsulato nel certificato digitale dell'utente 

role

ruoli che l'utente può ricoprire

mail

indirizzo di posta elettronica dell'utente (opzionale)

USERS

id

è l'identificatore del singleton

DOMAIN

domain

è il nome del dominio

description

descrizione del dominio (opzionale)

policy

politica valida in tutti i place del dominio (dati codificati in base64)

PLACE

place

è il nome del place

description

descrizione del place (opzionale)

policy

politica valida in questo place (dati codificati in base64)



Nella sezione  configurare il server ldap  vengono mostrati i passi necessari per mantenere questa struttura in un server ldap e un esempio completo.

Come è possibile osservare gli utenti e i ruoli sono definiti al livello del security domain.
Le politiche vengono definite a livello di SOMA domain e SOMA places.

Osservazione: l'oggetto role ha un attributo binario di nome “DC”, il cui valore unico rappresenta il certificato digitale di ruolo. Per estrarre il certificato digitale da un profilo Entrust è stato sviluppato il programma

SOMA.security.ldapauth.bindRoleDC

che accetta i seguenti argomenti: URL server ldap, file profilo, password profilo, nome ruolo. Per esempio:

java SOMA.security.ldapauth.bindRoleDC ldap://127.0.0.1 /profili/andrea secret student

lega all'oggetto role di nome “student” residente nel server ldap dell'host locale, il certificato digitale incapsulato nel profilo Entrust ”/profili/andrea” che è protetto dalla password “secret”.


Definire la gerarchia dei ruoli

Gli oggetti ROLES hanno un attributo binario denominato java_class. Per definire le gerarchie si è scelto di utilizzare il linguaggio java come un linguaggio di specifica utilizzando la relazione is-A esprimibile attraverso il costrutto class.....extends....
In questo modo si sono ottenute forti semplificazioni nello sviluppo dei controlli di autorizzazione e si è ottenuta una buona efficienza.
Per comprendere come si possa definire una gerarchia prendiamo in considerazione un esempio completo. Supponiamo di dover modellare la seguente gerarchia:

    administator
    guest

Il seguente codice java permette di specificare la gerarchia voluta:

administrator.java

guest.java

import SOMA.security.ldapauth.RolePrincipal;

public class administrator extends RolePrincipal
{
    public administrator(String name)
    {
    }
}

import SOMA.security.ldapauth.RolePrincipal;

public class guest extends administrator
{
    public guest(String name)
    {
    super(name);
    }
}

compilando i files administrator.java e guest.java si ottengono i bytecodes administrator.class e guest.class.
Questi bytecodes saranno gli attributi java_class degli oggetti ROLE identificati dai seguenti dn nel servizio di directory:

role=administator, id=roles, o=SOMA
role=guest, id=roles, o=SOMA


Configurare il server LDAP

In questo paragrafo si fa riferimento alla configurazione del server ldap openldap distribuito liberamente sotto GPL, nel sistema Linux. E' possibile ottenere una copia del software e maggiori informazioni presso http://www.openldap.org .

Il pacchetto openldap mette a disposizione il server ldap insieme ad una serie di tool che permettono di amministrare la directory.

Le entries nella directory vengono specificate nel formato ldif (LDAP Data Interchange Format). Un esempio di tale formato è il seguente:

dn: cn=Rebecca, id=users, o=SOMA
entrust_dn: C:IT, O:IngBo, SerialNumber 123456789 CN:Rebecca
cn: Rebecca
role: administrator
role: guest
objectClass: SOMAuser

che specifica la entry relativa ad uno user specificando che esso potrà ricoprire nel sistema i ruoli administarator e guest.
Per maggiori informazioni sul formato LDIF invocare:

man 5 ldif

E' quindi necessario definire un file (chiamato, per esempio, "/etc/openldap/dit") che, in formato ldif, specifichi completamente le entries della directory.
Per inciso, è possibile definire un attributo binario operando una codifica in base64 dei dati, cosa che può essere facilmente ottenuta eseguendo il comando ldif. Per esempio, i seguenti comandi sono relativi alla generazione dell'attributo java_class del ruolo administrator, e alla generazione dell'attributo policy del place Roma

ldif -b java_class < administator.class
ldif -b policy < Italia-Roma.policy

A questo punto è necessario definire il file di configurazione del server (chiamato, per esempio, "/etc/openldap/slapd.conf").
Per maggiori informazioni su questo passo invocare:

man slapd.conf

Una volta definiti i file che abbiamo chiamato /etc/openldap/dit e /etc/openldap/slapd.conf, possiamo generare il data base relativo alla nostra directory invocando il comando:

ldif2ldbc -f /etc/openldap/slapd.conf -i /etc/openldap/dit

Fatto questo è possibile lanciare il server:

slapd -f /etc/openldap

Il processo di configurazione qui descritto prevede di generare off-line la directory e poi lanciare il servizio. E' anche possibile gestire la directory on-line attraverso alcuni programmi che presentano anche una intuitiva interfaccia grafica; si cita a questo rigurado il programma kldap disponibile su piattaforma Linux con desktop KDE.


Un esempio completo di configurazione

In questo paragrafo vengono presentati tutti i file di configurazione necessari a lanciare il S.S.S. su un sistema Linux.

file di configurazione del server ldap:  myslapd.conf

files di definizione delle politiche nei vari places:

 Italia.policy
 Italia-Roma.policy
 Italia-Bologna.policy
 Francia.policy
 Francia-Parigi.policy
 default.policy
 

file di definizione della directory in formato ldif:  dit

OSSERVAZIONE: ovviamente le politiche sono mantenute dal server ldap come attributi degli oggetti place e domain.

per lanciare il S.S.S.

  1. IMPORTANTE: affinchè la macchina virtuale java utilizzi il policy provider del S.S.S. è necessario editare il file java.security tipicamente posizionato in <JDK_DIR>/jre/lib/security/java.security, aggiungendo il seguente comando: auth.policy.provider=SOMA.security.ldapauth.ldapPolicy. E' importante notare che questo policy provider, se non è specificata la system property securityDomain, si comporta come il provider di default (PolicyFile) e quindi le altre applicazioni non risentiranno del cambiamento

  2. specificare i ruoli e le gerarchie dei ruoli attraverso l'uso di java (come spiegato nel paragrafo  ruoli ); compilare le definizioni

  3. specificare le politiche utilizzando il linguaggio di specifica utilizzato da JAAS (per maggiori informazioni fare riferimento agli esempi e al seguente link: http://java.sun.com/security/jaas/doc/api.html#Policy

  4. definire la struttura della directory come spiegato nel paragrafo politiche definendo il file "dit"

  5. generare il db relativo alla directory con il comando   : ldif2ldbm -f myslapd.config -i dit

  6. lanciare il servizio di directory invocando il comando: slapd -f myslapd.config

  7. lanciare SOMA indicando le seguenti opzioni all'interprete java:

-Djava.security.manager 

impone all'interprete di usare il security manager

-Djava.security.policy=soma.policy 

politica di sicurezza del meccanismo di sicurezza standard di java. Il S.S.S. utilizza il meccanismo di sicurezza JAAS e non quello standard ma è comunque necessario specificare una politica

-Djava.security.auth.login=
   SOMA/security/ldapauth/policy/jaas.config

file di configurazione di jaas

-DsecurityServer=ldap://127.0.0.1 

questa opzione indica il security domain al quale agganciare questa istanza di SOMA. Vedi 

-cp roles/:.

è necessario indicare nel classpath la directory roles