Lezione del 27 germile 216 (16.4.2008)
Torna alla pagina di ESP
Politiche amministrative
Queste politiche servono per stabilire chi può concedere o revocare autorizzazioni. Nelle mandatorie, c'è 1 amministratore centrale che decide la classe dei soggetti, e la classe degli oggetti dipende da chi la crea. Quindi, solo l'amministratore decide chi può fare cosa.
Ci sono comunque diversi paradigmi di politiche amministrative:
- centralizzata: 1 amministratore
- gerarchica: 1 amministratore, con delega ad altri utenti
- cooperativa: diversi amministratori, e le auth devono essere rilasciate da tutti
Le più usate sono:
- ownership: chi crea un oggetto ne è il proprietario, e dà lui i permessi agli altri su quell'oggetto
- decentralizzata: non vuol dire cooperativa, ma vuol dire che diversi utenti fanno quello che vogliono nelle zone a loro dedicate, delegando etc.
I problemi riguardano soprattutto tenere traccia in modo chiaro di chi può fare che cosa, come gestire le deleghe, e che cosa accade quando un'autorizzazione viene revocata.
Con la delega ristretta, si può decidere se i privilegi vanno dati in blocco, oppure possono essere dati in modo selettivo.
Per quanto riguarda la revoca, è il solito problema: A autorizza B, e B autorizza C. Poi ad A viene tolta dal Grande Capo l'autorizzazione. Che accade a B e C, a cui i poteri sono stati dati da A, il quale ormai non ne ha più?
La soluzione di questo problema dipende da come è organizzato il sistema. Nei DBMS in generale si sceglie se le revoche vadano a cascata, o no.
DBMS
I DBMS relazionali che usano SQL usano una politica decentralizzata, combinata con il concetto di ownership: chi crea qualcosa, ne è l'admin.
Poi c'è la faccenda del GRANT:
GRANT SELECT ON TABLE brao TO ukulele WITH GRANT OPTION
Si decide cioè che permessi dare, su che oggetti, a chi, e si specifica, con la GRANT OPTION, se quell'utente potrà a sua volta rilasciare quei permessi a qualcun altro.
DAC avanzate
Le DAC viste finora usavano una tripla (U,A,O) = Utente, Azione, Oggetto, ma sono poco espressive.
Quindi, si estende l'idea con una cosa così: (U, A, O, Condizione). La semantica di questa quadrupla è che il privilegio si applica all'utente SSE la condizione è soddisfatta.
Le condizioni possono essere di qualunque tipo: ora del giorno, amicizia con il padrone, il contesto e così via.
Autorizzazioni per gruppi
Quando ci sono tanti utenti, non è molto comodo dover assegnare a ciascuno decine e decine di privilegi.
Si introduce quindi l'astrazione di una gerarchia, definita su soggetti o oggetti o altri componenti, in cui i privilegi in cima alla gerarchia si propagano a tutti i "figli".
Posso anche decidere di non propagare automaticamente i privilegi, oppure subordinare dei privilegi alla presenza di altri privilegi, che magari dovrei ottenere da altri cammini gerarchici.
Ma c'è il problema che è difficile dare privilegi ad un solo utente, cioè tirarlo fuori dalla gerarchia per fargli fare qualcosa di specifico. Per intenderci, è inutile e magari rischioso autorizzare il lavavetri ad entrare nel Sancta Sanctorum, in genere riservato al Grande Capo, solo per pulire la bacheca.
E allora, si introducono delle eccezioni, applicate direttamente ai nodi, che rappresentano, a seconda del tipo di gerarchia, un utente o un oggetto.
Autorizzazione positiva: (Utente, Azione, Oggetto, +)
Autorizzazione negativa: (Utente, Azione, AltroOggetto, -)
dove + significa il poter fare l'azione, - no.
Nelle politiche aperte, le autorizzazioni specificano negazioni.
Nelle politiche chiuse, invece, le autorizzazioni specificano permessi.
In una politica aperta uno può fare quello che gli deriva dalla gerarchia, a meno di eccezioni. Al contrario, in una politica chiusa, uno non può fare niente a meno di eccezioni. Le autorizzazioni negative permettono di esprimere sia politiche aperte, che chiuse.
Non è tutto rose e fiori. Ci sono dei problemi:
- inconsistenza: se da una parte ad un utente viene un +, e dall'altra un -, chi vince?
- non completezza: ci saranno oggetti senza + né -? Se sì, come mi comporto?
Per l'inconsistenza, ho queste soluzioni:
- Denials take precedence = vincono i NO, anche se sono in parità
- Most Specific Takes Precedence (MSTP) = vince l'autorizzazione più specifica
- Most Specific Along A Path Takes Precedence (MSAPTP) = si confrontano le più specifiche su ogni percorso di autorizzazione, per vedere chi vince.
Questi sono i modi per risolvere i conflitti tra autorizzazioni discordanti. Se decido che vincono sempre i + o i - in un conflitto, è semplice. Con le altre tecniche, un po' meno.
MSTP
Devo prendere l'autorizzazione più specifica nella mia gerarchia, ed applicare quella.
Però, se diversi cammini portano allo stesso utente (o oggetto), e al nodo precedente uno dice + e l'altro dice -, chi vince?
(de)Càpita quindi che ci siano conflitti non risolvibili con la MSTP, anche se a prima vista sembra bella.
MSAPTP
Qui devo valutare tutti i percorsi che si dipanano dal mio oggetto (o utente). Per ogni percorso che risale alla radice, vedo qual'è l'autorizzazione più specifica.
Se tutti sono d'accordo, il conflitto è risolto. Non lo è però quando non tutti i percorsi sono d'accordo, quindi nemmeno MSAPTP è perfetta.
Strong VS Weak
Un altro sistema è quello di dire: ci sono autorizzazioni forti e autorizzazioni deboli, e le auth forti vincono sempre su quelle deboli.
Nel caso invece di scontro tra due autorizzazioni deboli, si usa la MSAPTP.
Ma nemmeno questa è del tutto efficace:
- ci sono solo 2 livelli di priorità
- le autorizzazioni forti devono essere consistenti, se no non servono a nulla
Il secondo punto significa che se ho una forte contro una debole, so chi vince. Ma se ho una forte contro una forte, e dicono cose diverse, chi vince?
Si obbliga quindi l'amministratore a concedere le autorizzazioni forti in modo che non creino questi problemi di consistenza, ma allora questa tecnica non risolve in modo automatico tutti i conflitti...
Altre politiche
Posizionale: ho una lista ordinata di autorizzazioni. L'ultima data è quella che fa testo.
Grantor-Dependent: dipende da chi mi ha dato l'autorizzazione.
Time-Dependent: la priorità dipende da quando sono state concesse le autorizzazioni.
Torna alla pagina di ESP
