Newsgroup: it.comp.os.dibattiti
Titolo: [Fwd: Published: "Thirty Years Later: Lessons from the Multics SecurityEvaluation"]


Organization: iPrimus Customer - reports relating to abuse should be
sent to 
ab...@iprimus.com.au
Newsgroups: alt.os.multics
Paul A. Karger (IBM) and Roger R. Schell (Aesec Corporation) have 
published a paper,  "Thirty Years Later: Lessons from the Multics 
Security Evaluation":
http://domino.watson.ibm.com/library/cyberdig.nsf/papers/FDEFBEBC9DD3E35485256C2C004B0F0D/$File/RC22534.pdf
 From the Introduction, "The results [of a 1974 Air Force audit of 
Multics] are still interesting today, because many of the concepts of 
UNIX and other modern operating systems came directly from Multics. This 
paper revisits those results and relates them to the widespread security 
problems that the computer industry is suffering today. The unpleasant 
conclusion is that although few, if any, fundamentally new 
vulnerabilities are evident today, today's products generally do not 
even include many of the Multics security techniques, let alone the 
enhancement identified as 'essential.'"
via /. thread ( 
http://slashdot.org/article.pl?sid=02/09/09/179246&mode=thread&tid=172
 )
Toby


Mhh... nessuno per il momento replica al post, eppure materiale per discutere ce ne sarebbe, e anche molto.
:-)
Il documento pdf contiene, oltre a "thirty years later: lessons from the multics security evaluation", pag.
1-10, il documento originale "Multics security evaluation: vulnerability analysis", nelle pagine 11-34.
Per chi ha la pazienza di leggersi un pdf di poche pagine, puo' andare a vedere le sezioni (anche se IMHO e'
meglio leggerlo integralmente):
2.2 Security as standard product feature
    Il sistema viene distribuito con *tutti* i requisiti di sicurezza, non come add-on successivi...
2.3 No buffer overflows
    La programmazione in "c", a differenza di quella in linuguaggi come PL/I, e' incline ai buffer overflow...
2.3.2 Hardware features for better security
      Oggi nessuno dei sistemi operativi maggiormente diffusi per x86 usa la protezione contro l'esecuzione di
codice su pagine/segmenti destinate a contenere dati... sulla falsariga dei buffer overflow, cio' renderebbe ad
esempio piu' difficile il successo di tecniche di "code-injection".
2.4 Minimizing complexity
      La complessita' delle componenti di sistema, in primis il kernel, e' un nemico primario della sicurezza.
bye G.L.
--
La logica non attiene alla verosimiglianza delle ipotesi,
ma alla coerenza delle tesi con le ipotesi.

       kernel, e' un nemico primario della sicurezza.
Sacrosanto, ma anche questa fa a pugni con il sw commerciale.
La situazione e' meno drammatica nel sw non commerciale.
E' un dato di fatto che 30 anni fa i sistemi (o Multics in particolare)
erano piu' sicuri.  Oggi in teoria dovremmo avere dei sistemi 
ultrasicuri, ma non e' cosi'.
Il motivo secondo ma e' la massificazione del computer, il PC.
E' una questione di compromessi, se vuoi piu' sicurezza devi sacrificare
qualcosa e molto spesso questo "qualcosa" non e' sacrificabile.
Costi di certificazione e usabilita' sono i principali ostacoli.
Scrivere un sw che abbia un certo grado di affidabilita' costa e non
sempre questa caratteristica e' cosi' desiderata, paradossalmente.
La situazione e' ancora peggiore con l'hw, qui siamo in pieno far west.
In secondo luogo c'e' il problema dell'usabilita' per l'utente finale.
Schemi di sicurezza come ad esempio il Mandatory Access Control non sono
proprio il massimo dello "userfriendly".
I tempi cambiano, se 30 anni fa le migliaia di utenti di Multics
seguivano corsi e imparavano ad usare il sistema con questi schemi
di sicurezza, oggi non puoi pretendere la stessa cosa dall'utente
Joe che vuole solo (legittimamente) ripparsi i suoi CD :)
-- 
Lorenzo

 ultrasicuri, ma non e' cosi'.
D'accordo, ed e' espresso chiaramente nel documento, che tra l'altro parla di sistemi *server* pensati dal
*principio* con concetti e strutture orientate alla sicurezza, oltre che forniti dalla base con tutto il
necessario per la sicurezza *in-bundle*.
Il discorso che fai di seguito e' IMHO accettabile sempre che si prenda per buona l'attuale situazione in cui un
sistema concepito inizialmente per l'ambiente home/desktop e' basilarmente lo stesso che, pur evoluto, si e'
usato per un sistema server: qualcosa che non va ci deve pur essere...
Parla persino di installazioni militari in cui la sicurezza ai tempi di multics e' ora una chimera (pare di
capire).
Ovvio che, ne convengo, se ne e' discusso in mille salse, chiaro che in passato, facendo un esempio banale a
caso, quasi nessuno poteva permettersi a casa una workstation sun (e neanche, piu' avanti, una acorn 140 con bsd
unix a 6ml contro circa 3ml di un intel)... la diffusione commerciale del pc e' stata determinante in tutto
questo.


 va ci deve pur essere...
Ho trovato un esempio interessante:
XST-300 e' un sistema di classe B3 (il massimo, dopo c'e' solo la classe 
A1 che non e' mai stato raggiunta da nessun OS), basato su i486:
http://www.gcn.com/archives/gcn/1995/October15/xts300.htm
"Prices start at $33,000 for a system with STOP, 16M of system memory, a 
500M hard drive, a tape drive, a 3 1/2-inch floppy drive and one 
parallel and two serial ports. A "guard" version that sits between two 
networks and contains a coded security policy is available for about 
$44,000. Removable disk drives are an option on both versions."
Sono prezzi di 7 anni fa.  A occhio direi che a quei tempi un 486
costava circa 20 volte meno.
Senza contare i costi di manutenzione:
"Each future upgrade to the XTS-300 design will require separate NSA 
approval, but new approvals should not take two years. Establishing an 
upgrade path was part of the initial NSA requirement, LeBlanc said."
Non credo che NSA certifichi gratis :)
Insomma, c'e' almeno un caso di un sistema inizialmente concepito per
l'home/desktop che e' stato trasformato in un mostro corazzato, ma
a caro prezzo :)
-- 
Lorenzo