Re: codice corretto, codice robusto, codice sicuro

Preciso che sto rispondendo alla prima versione del post, se hai gia'
modificato le cose nella seconda lascia stare :P

> (definizione di stato?)

Se stiamo parlando di macchine astratte, lo stato di un programma non si
"definisce", ma e' parte della definizione di "macchina" (e quindi di
programma :)

> Un programma è robusto se, sottoposto ad input invalidi, fornisce output
> validi.

Mi sfugge il concetto di valido in relazione a un input imprevisto.

> Questo significa che un programma robusto dovrà fornire output
> coerenti con le specifiche anche se sottoposto ad input imprevisti.

Quindi, le specifiche devono descrivere anche come trattare input
imprevisti, e tale "trattamento" deve essere correttamente implementato.
Giusto.

> nozione di robustezza di un programma non ha una definizione che indichi
> precisamente cosa si debba fare per ottenere software robusto.

Comportarsi secondo le specifiche !

Sono le _specifiche_ che devono essere robuste !

> Un programma è sicuro se, sottoposto ad input invalidi e/o validi, si
trova
> sempre in uno stato valido.

Andrebbe definito in modo piu' rigoroso il concetto di "stato valido". Male
che vada come definizione puoi prendere quanto scrivi dopo:

> 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.

Poi:

> · un programma robusto è anche corretto;

Vero.

> · un programma non sicuro potrebbe comportarsi in modo corretto e robusto;

Non vedo come.

> · un programma sicuro potrebbe essere non corretto e non robusto;

Di nuovo non vedo come.

Un programma non corretto NON fornisce un servizio a un utente che lo
richiede correttamente. Viola il principio di disponibilita', e per la
definizione classica di sicurezza, non e' sicuro.

Un programma non robusto puo' comportarsi in modo "non specificato" in
seguito all'immissione di input invalidi. Vedo difficile descrivere cio'
come "sicuro". Dici tu stesso:

> 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.

Poi:

> 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.

Questo paragrafo andrebbe sostenuto, non e' affatto palese che sia vero cio'
che dici e anzi mi trova in netto disaccordo.

>  Siccome un programma
> è sicuro se il suo stato è valido

Qui mi pare che tu ti contraddica, se non e' cosi' ho capito male e mi
piacerebbe una spiegazione piu' chiara su questa dicotomia valido/sicuro.

Stefano "Raistlin" Zanero
System Administrator Gioco.Net
public PGP key block at http://gioco.net/pgpkeys



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