cerca
Tema d'Esame di Sicurezza e Privatezza - 12/09/2008
modifica cronologia stampa login logout

Wiki

UniCrema


Materie per semestre

Materie per anno

Materie per laurea


Help

Tema d'Esame di Sicurezza e Privatezza - 12/09/2008

Torna alla pagina di Sicurezza & Privatezza


 :: Appello d'esame di Sicurezza e Privatezza - 12/09/2008 ::

Domande

Rispondere brevemente ma in modo completo alle seguenti domande.

  1. Descrivere a quale possibile attacco è vulnerabile la tecnica di autenticazione basata sul meccanismo di challenge-response. La risposta deve essere ben motivata fornendo anche un esempio.
  2. Nell’ambito del modello a matrice di accesso, fornire la definizione di stato di protezione e descrivere i comandi primitivi che possono essere usati per cambiare lo stato.
  3. Descrivere la politica low-water mark per soggetti e per oggetti ed i loro svantaggi.
  4. Descrivere lo smurf attack.
  5. Nell’ambito delle politiche di risoluzione dei conflitti, descrivere le politiche most-specific-takes-precedence (mstp) e most-specific-along-a-path-takes-precedence (msaptp). Si richiede inoltre di fornire un unico esempio di gerarchia utenti-gruppi con relative autorizzazioni e che illustri che per l’utente Alice non c'è una autorizzazione vincente (deve rimane un conflitto +/-) sia quando si applica la politica mstp sia quando si applica la politica msaptp.
  6. Descrivere le informazioni che un firewall di tipo packet filterig può analizzare per filtrare i pacchetti. Questi firewall sono in grado di tracciare delle correlazioni tra i pacchetti di una trasmissione?
  7. Nell’ambito di PGP, descrivere il processo combinato di segretezza ed autenticazione.
  8. Descrivere le caratteristiche principali ed i vantaggi e svantaggi di un sistema IDS di tipo misuse detection.

SOLUZIONE

1.
La tecnica di autenticazione basata sul meccanismo di challenge-response è vulnerabile ad attacchi attivi, ad esempio man in the middle attack.
In questo scenario l'avversario si dichiara al posto del token nei confronti del server e si mostra come server nei confronti del token, questo gli permette di autenticarsi utilizzando la risposta corretta generata direttamente dal token.
Immagine chiarificatrice:

dove R = response del token al server
C = challenge del server al token
e l'avversario è ovviamente Babbo Natale.

2.
Lo stato di protezione è definito dalla tripla (s,o,a) dove:

  • S: insieme dei soggetti (righe della matrice)
  • O: insieme degli oggetti (colonne della matrice)
  • A: matrice di accesso formata dai soggetti e dagli oggetti e dove A[s,o] indica le azioni del soggetto s sull'oggetto o.

Lo stato di protezione può essere modificato tramite dei comandi primitivi:

  • enter r into A[s,o]
  • delete r from A[s,o]
  • create subject S'
  • destroy subject S'
  • create object O'
  • destroy object O'

3.
Politica low-water mark per soggetti:

  • il soggetto S può scrivere un oggetto O se e solo se: λ(s) > λ(o)
  • il soggetto S può leggere qualsiasi oggetto, però questo va a modificare la sua affidabilità: λ(s) = glb{λ(s),λ(o)}

Svantaggio: l'ordine delle operazioni modifica i privilegi del soggetto. Infatti abbiamo visto che il soggetto può leggere qualsiasi cosa, però questo va a modificare la sua classe d'integrità, cioè la sua affidabilità. Quindi può capitare che un soggetto S, che prima poteva scrivere un determinato oggetto O, non sia più in grado di farlo dopo aver letto un altro oggetto che ha fatto diminuire la sua classe di integrità.

Politica low-water mark per oggetti:

  • il soggetto S può leggere un oggetto O se e solo se: λ(o) > λ(s)
  • il soggetto S può scrivere qualsiasi oggetto, però questo va a modificare l'oggetto stesso: λ(o) = glb{λ(s),λ(o)}

Svantaggio: non protegge l'integrità, ma si limita a segnalare che è stata compromessa.

4.
Nello smurf attack l'attaccante intasa la vittima sfruttando il protocollo ICMP. Infatti invia una ICMP Echo Req con fonte: indirizzo vittima e destinazione: indirizzo broadcast(quindi tutti gli host della rete locale). Quindi tutte le macchine che ricevono la richiesta generano una ICMP Echo Reply diretta alla vittima, così facendo le risposte generate intaseranno la vittima.
Slide chiarificatrice:

5.
La politica mstp(most specific takes precedence) comporta che vince l'autorizzazione più specifica rispetto a tutto lo schema. La politica msaptp(most specific along a path takes precedence) invece comporta che vince l'autorizzazione più specifica rispetto ad un cammino. L'autorizzazione più specifica vince sui cammini che passano dall'autorizzazione.

Esempio utenti-gruppi:

6.
Un firewall di tipo packet filtering analizza i pacchetti solo sulla base delle informazioni dell'header:

  • indirizzo sorgente
  • indirizzo destinazione
  • porta sorgente
  • porta destinazione
  • tipo di protocollo
  • opzioni di protocollo

Il packet filtering non è in grado di tracciare delle correlazioni tra i pacchetti di una trasmissione, mentre lo stateful packet filtering si.

Esercizio 1

Si consideri un sistema UNIX con:

  • utente alice, membro dei gruppi alice (gruppo principale) e spdp;
  • utente bob, membro del gruppo bob;
  • directory /users/alice/myfile contenente i seguenti file

dove l'esegubile mygame.x crea un file mygameres.dat che può essere letto e scritto dal suo proprietario e letto dal suo gruppo e da tutti gli altri utenti; l'eseguibile frog.x crea un file out.dat che può essere letto dal suo proprietario e dal suo gruppo.
Si suppone che alice esegue un programma mygame.x e successivamente bob esegue il programma frog.x. Rispondere alle domande specificate.

SOLUZIONE

1. Elencare i file che alice può leggere:

  • Algo.tex -> Si applicano i permessi del proprietario (che è appunto alice), ove è presente il r;
  • mygame.x -> Si applicano i permessi per gli altri (terza tripletta dei permessi), ove è presente il r;

2. Elencare i file che il processo corrispondente all'esecuzione del file mygame.x da parte di alice può scrivere:

Prima di tutto si verifica se effettivamente alice possa eseguire il programma. Alice può eseguirlo in quanto nei permessi del file mygame.x esiste il permesso di esecuzione per gli altri, in quanto non si applicano né quelli del proprietario, né quelli del gruppo. I file che alice può scrivere dunque sono:

  • Algo.tex -> Si applicano i permessi per il proprietario, dove è presente il w;
  • result.txt -> Si applicano i permessi del gruppo, dove è presente il w

3. Indicare il proprietario ed il gruppo del file mygamesres.dat (può essere letto e scritto dal proprietario e letto dal gruppo):
Il proprietario è alice. Ad un oggetto non si associa mai più di un gruppo, in questo caso avendo alice due gruppi (quello di alice e spdp), all'oggetto si associa sempre quello principale dunque il gruppo alice.

4. Elencare i file che bob può leggere:

  • mygame.x -> Si applicano i permessi del proprietario (che in questo caso è proprio bob) dove è presente il r.

5. Elencare i file che il processo corrispondente alla esecuzione di frog.x (da parte di bob DOPO che alice ha eseguito mygame.x) può leggere:

Il significato del DOPO è che oltre ai file presenti nella tabella dobbiamo aggiungere mygameref.dat

Permessi

Owner

Gruppo

Nome file

rw- r-- r--

alice

alice

mygameref.dat

Come detto nel testo dell'esercizio alice esegue il file mygame.x, il quale genere appunto il nostro mygameref.dat. Dato che bob lancia questo file l'UserID e il GroupID del file variano :

  • UserID: bob
  • GroupID: root

I file che il processo può leggere sono:

  • mygame.x -> Si applicano i permessi del proprietario;
  • frog.x -> Si applicano i permessi del gruppo;
  • webconf.c -> Si applicano i permessi del gruppo.

Come detto prima oltre ai file della tabella dobbiamo verificare se il processo può leggere anche il file mygameref.dat. Per questo file non si applicano i permessi di proprietario, né tanto meno quelli del gruppo e per gli altri non è presente il r, dunque il processo non potrà leggere questo file.

Esercizio 2

Si consideri un Web server Apache e si supponga che l'utente Alice abbia creato nella sua directory www il file .htaccess riportato sotto. Per ogni richiesta di accesso specificata nella tabella sottostante, indicare se la richiesta viene accettata o rifiutata (permit o deny) e motivare la risposta.

SOLUZIONE

Richiesta di accesso

Decisione (permit/deny)

Motivazione

Da Bob su file myserver.log e proveniente dalla macchina 156.124.1.5

deny

Il file finisce in .log, dobbiamo quindi applicare le regole di <Files>. La richiesta di accesso viene negata perché si applica la Deny from all, che si applica a tutte le richieste di accesso.

Da Carol su file index.html e proveniente da mymachine.othernet.com.

permit

La richiesta viene permessa per via del Satisfy any(è sufficiente che la richiesta sia permessa da una parte sola, non per forza ovunque) e della presenza di Carol in Require user cioè nell'autorizzazione user_based.

Da Elen su file contact.html e proveniente dalla macchina 186.154.21.1.

permit

La richiesta viene permessa perché Elen fa parte del gruppo SPDP, quindi viene concessa per l'autorizzazione user_based ed è sufficiente per la Satisfy any.

Da Frank su file admin.php e proveniente dalla macchina 155.231.1.3.

deny

La richiesta viene negata perché non ci sono autorizzazioni user_based che la consentono. Frank infatti non fa parte di SPDP e degli user.

Esercizio 3

Si consideri l’insieme di livelli di segretezza L = {Stricly Confidential (SC), Medium Confidential (MC), Confidential (C), Low Confidential (LC) e Public (P)}, dove SC > MC > C > LC > P, e l’insieme di categorie Cat = {Medical (M), Financial (F), Security (S)}. Rispondere alle domande elencate nella tabella allegata, supponendo di applicare una politica mandatoria per la segretezza.

SOLUZIONE

1. Numero delle classi di sicurezza nel reticolo.

5*23 = 40

2. Elemento bottom (⊥) del reticolo.

<P,{}>

3. Elemento top (Τ) del reticolo.

<SC,{m,f,s}>

4. lub(<MC, {M,F}>, <C, {S}>)

<MC,{m,f,s}>

5. glb(<SC, {F}>, <P, {F,S}>)

<P,{f}>

6. Elencare le classi di sicurezza che un utente con clearance <LC, {F,S}> può usare per collegarsi al sistema.

<LC,{f,s}>, <P,{f,s}>
<LC,{s}>, <P,{s}>
<LC,{f}>, <P,{f}>
<LC,{}>, <P,{}>

7. Elencare le classi di sicurezza degli oggetti che possono essere scritti da un soggetto di classe <MC, {M}> (se non esiste nessuna classe scrivere nessuna)

<MC,{m}>, <SC,{m}>
<MC,{m,s}>, <SC,{m,s}>
<MC,{m,f}>, <SC,{m,f}>
<MC,{m,s,f}>, <SC,{m,s,f}>

8. Elencare le classi di sicurezza degli oggetti che possono essere letti da un soggetto di classe <LC, {M}>(se non esiste nessuna classe scrivere nessuna)

<LC,{m}>, <P,{m}>
<LC,{}>, <P,{}>

9. Siano s1 e s2 due soggetti con classe λ(s1) = <MC, {M,F}> e λ(s2) = <SC, {M}>. Elencare le classi di sicurezza degli oggetti che possono essere usati per trasferire informazioni da s1 a s2 (s1 → s2) e da s2 a s1 (s2 → s1).(se non esiste nessuna classe scrivere nessuna)

s1 → s2
nessuna

s2 → s1
nessuna

10. Siano s1 e s2 due soggetti con classe λ(s1) = <SC, {F,S}> e λ(s2) = <P, {S}>. Elencare le classi di sicurezza degli oggetti che possono essere usati per trasferire informazioni da s1 a s2 (s1 → s2) e da s2 a s1 (s2 → s1).(se non esiste nessuna classe scrivere nessuna)

s1 → s2
nessuna

s2 → s1
<SC,{f,s}>, <SC,{s}>
<MC,{s}>, <MC,{s}>
<C,{f,s}>, <C,{s}>
<LC,{f,s}>, <LC,{s}>
<P,{f,s}>, <P,{s}>


Torna alla pagina di Sicurezza & Privatezza