codice corretto, codice robusto, codice sicuro (ver. 2)

Ho meglio precisato quanto precedentemente detto.


___________________________________________
Application and Environment
Osservando che molti problemi di sicurezza nascono da una inappropriata
interazione tra programma e l'ambiente in cui esso è eseguito, si è
proceduti a distinguere i sistemi in "application" ad "enviroment". In base
a questa suddivisione daremo le seguenti definizioni.
Definizione  (Internal Entity) Ogni elemento del codice di una applicazione
e dello spazio dati della stessa, rappresentano un internal entitity.
Definizione  (Internal State) L'insieme dei valori assunti  dalle internal
entity di una applicazione è detto internal state.
La variabile var di una applicazione, per esempio, è una internal entity. Il
valore di var è parte dell'internal state. La dimensione del buffer
adoperato per l'internal entità var è anch'essa parte dell'internal state.
In generale tutte le informazioni relative al codice ed ai dati di una
applicazione, ad esempio stack space, heap space, data space, sono parte
dell'internal state.
Definizione (Environment Entity) Ogni elemento che è esterno al codice di
una applicazione ed al proprio spazio dati è detto enviroment entity.
Definizione (Environment State) L'insieme dei valori assunti  dalle
enviroment entity di una applicazione è detto enviroment state.
Ad esempio i files sono eviroment entity. L'esistenza di un file, i permessi
su un file sono invece parte dell'enviroment state.

Codice corretto, robusto, sicuro
In questo paragrafo saranno date le definizioni di codice corretto, codice
robusto, e codice sicuro  e verranno analizzate le relative differenze.
Suddividiamo l'input, l'output, l'internal state e l'environment state di
una applicazione in "validi" ed "invalidi", dove per validità si intende la
coerenza con le specifiche date.
Definizione (Programma corretto) Un programma è corretto se si comporta come
previsto dalle proprie specifiche; in altre parole un programma è corretto
se, sottoposto ad input validi, fornisce output validi.
Definizione (Programma robusto) Un programma è robusto se, sottoposto ad
input validi e/o invalidi, comunque fornisce output validi. Questo significa
che un programma robusto dovrà fornire output coerenti con le specifiche
anche se sottoposto ad input imprevisti. La nozione di robustezza di un
programma non ha una definizione che indichi precisamente cosa si debba fare
per ottenere software robusto. Da un programma robusto ci si aspetta che sia
corretto ma che sia in grado di comportarsi correttamente anche in presenza
di situazioni non previste in origine (o dalle specifiche?).
Definizione (Programma sicuro) Un programma è sicuro se, sottoposto ad input
invalidi e/o validi, l'internal state e l'environment state sono validi. Il
fatto che il programma sia sempre in uno stato valido consente di evitare
comportamenti anomali, volutamente o involontariamente prodotti, che
possono, in un modo o in un altro, consentire al programma di eseguire
operazioni non desiderate.

figura 1 - programma corretto, robusto, sicuro.

Le definizioni  date rendono chiare le seguenti implicazioni:
· un programma robusto è anche corretto;
· un programma non sicuro potrebbe comportarsi in modo corretto e robusto;
· un programma sicuro potrebbe essere non corretto e non robusto;
In altre parole non c'è alcun legame diretto tra la robustezza/correttezza
di un programma e la sua sicurezza. Tuttavia è opportuno osservare che la
definizione data di programma sicuro presuppone che il programma stesso
reagisca ad input validi o/e invalidi in modo da portarsi sempre in uno
stato valido. Quando questo è possibile contrasta con requisiti di
efficienza e complessità; quando non è possibile contrasta con i requisiti
di funzionalità in quanto alcuni input e/o output non possono essere gestiti
e quindi accettati dal programma in quanto porterebbero lo stesso,
inevitabilmente, in uno stato non valido.
Meritevole di nota è poi la scelta di distinguere lo stato di un programma
in valido e/o invalido e non in sicuro e/o non sicuro. Siccome un programma
è sicuro se il suo stato è valido potrebbe sembrare più opportuno parlare di
stato sicuro e/o non sicuro; questa scelta tuttavia nasconderebbe una
ambiguità di fondo. Uno stato non è mai sicuro di per sé ma lo è in
riferimento ad una specifica di programma (vedi paragrafo successivo). Pare
quindi più corretto parlare di stato valido che di stato sicuro.
Nei capitolo successivi saranno analizzate le vulnerabilità più comuni e
definite per ognuna di esse uno stato valido.
_________________________________________

----- Original Message -----
From: "Orlando Onorato" <disgry@libero.it>
To: <ml@sikurezza.org>
Sent: Saturday, April 20, 2002 4:05 PM
Subject: codice corretto, codice robusto, codice sicuro


> Salve a tutti,
> nello scrivere la mia tesi ho dovuto affrontare il problema
> di definire la programmazione corretta, robusta e sicura.
> Sottopongo a quanti interessati la mia soluzione, attendendo
> una vostra opinione in merito.
>
> _____________________________
>
> Suddividiamo l'input, l'output e lo stato di un programma in "validi" ed
> "invalidi", dove per validità si intende la coerenza con le specifiche.
> (definizione di stato?)
> Un programma è corretto se si comporta come previsto dalle proprie
> specifiche; in altre parole un programma è corretto se, sottoposto ad
input
> validi, fornisce output validi.
> Un programma è robusto se, sottoposto ad input invalidi, fornisce output
> validi. Questo significa che un programma robusto dovrà fornire output
> coerenti con le specifiche anche se sottoposto ad input imprevisti. La
> nozione di robustezza di un programma non ha una definizione che indichi
> precisamente cosa si debba fare per ottenere software robusto. Da un
> programma robusto ci si aspetta che sia corretto ma che sia in grado di
> comportarsi correttamente anche in presenza di situazioni non previste in
> origine (o dalle specifiche?).
> Un programma è sicuro se, sottoposto ad input invalidi e/o validi, si
trova
> sempre in uno stato valido. Il fatto che il programma sia sempre in uno
> stato valido consente di evitare comportamenti anomali, volutamente o
> involontariamente prodotti, che possono, in un modo o in un altro,
> consentire al programma di eseguire operazioni non desiderate.
>
> figura 1 - programma corretto, robusto, sicuro.
>
> Le definizioni  date rendono chiare le seguenti implicazioni:
> · un programma robusto è anche corretto;
> · un programma non sicuro potrebbe comportarsi in modo corretto e robusto;
> · un programma sicuro potrebbe essere non corretto e non robusto;
> In altre parole non c'è alcun legame diretto tra la robustezza/correttezza
> di un programma e la sua sicurezza. Tuttavia è opportuno osservare che la
> definizione data di programma sicuro presuppone che il programma stesso
> reagisca ad input validi o/e invalidi in modo da portarsi sempre in uno
> stato valido. Quando questo è possibile contrasta con requisiti di
> efficienza e complessità; quando non è possibile contrasta con i requisiti
> di funzionalità in quanto alcuni input e/o output non possono essere
gestiti
> e quindi accettati dal programma in quanto porterebbero lo stesso,
> inevitabilmente, in uno stato non valido.
> Meritevole di nota è poi la scelta di distinguere lo stato di un programma
> in valido e/o invalido e non in sicuro e/o non sicuro. Siccome un
programma
> è sicuro se il suo stato è valido potrebbe sembrare più opportuno parlare
di
> stato sicuro e/o non sicuro; questa scelta tuttavia nasconderebbe una
> ambiguità di fondo. Uno stato non è mai sicuro di per sé ma lo è in
> riferimento ad una specifica di programma. Pare quindi più corretto
parlare
> di stato valido che di stato sicuro.
> ___________________________
>
> ciao,
> Orlando
>
>
>


________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List