Linux Unix e i virus/Problemi di sicurezza/Multiutenza

Leggendo il paragrafo precedente, si intuisce qual è la differenza di base che rende Unix invulnerabile laddove Windows non ha difese: il concetto di multiutenza. Più precisamente, la netta distinzione tra la "modalità utente" e la "modalità amministrativa" e i rispettivi diritti di accesso. Windows 98 offre anche qualche strumento di gestione di diritti di accesso ai file e all'esecuzione di determinati applicativi e una qualche forma di multiutenza. Tuttavia non si tratta di una vera e propria multiutenza, ma di "regole" che un determinato utente imposta e che il sistema e gli applicativi sono pronti a rispettare... inutile dire che un virus certamente non si preoccupa di rispettare tali regole e può anche tranquillamente modificare gli attributi impostabili da MS-DOS (come la non rimovibilità)...

A questo punto si potrebbe obiettare che Windows NT offre una gestione della multiutenza e dei permessi di accesso in buona misura analoga a quella tradizionale di Unix, quindi l'utilizzo di Windows NT anziché 9x/ME dovrebbe risolvere il problema e annullare tale "distanza" tra Unix e Windows. Beh... cosa dire? Almeno in linea di principio, Windows NT offre una gestione di utenti e permessi perfino leggermente più versatile rispetto a Unix. Tuttavia, Windows NT presenta importanti debolezze strutturali in confronto alla rigorosa architettura del "grande vecchio" Unix. Ad esempio, di default le proprietà e i diritti di accesso dei file e delle directory di sistema lasciano molte maglie aperte agli utenti normali (quelli che su Windows 2000 sono chiamati "utenti standard"), che possono perfino scrivere nelle directory di sistema, come \, \winnt\, \winnt\system32 . In una situazione del genere risulta ben poco immediato identificare le parti di File System in cui un generico utente agisce e quindi diventa difficile anche limitare lo spazio occupato su disco da un generico utente. Cosicché è concreto anche il rischio che un qualunque utente blocchi il sistema riempiendo il disco per aver contratto un qualunque virus. Si potrebbe obiettare che basterebbe "richiudere tali maglie", cioè ricalibrare opportunamente - alla Unix - proprietà e diritti di accesso.

Anche volendo prescindere da una valutazione dei tempi di lavoro aggiuntivi legati a tale ricalibrazione e dal rischio di commettere errori nell'effettuarla, bisogna notare che applicativi di uso comune (anche applicativi prodotti dalla stessa Microsoft), per il loro "corretto" funzionamento, hanno bisogno dei permessi laschi offerti di default da Windows NT. Quindi la soluzione del problema comporterebbe una rivisitazione delle scelte architetturali e un insieme di interventi che danneggerebbero il funzionamento di software già installati sul sistema... difendiamo il sistema o lo facciamo funzionare? :) Inoltre, Windows NT non offre una buona protezione della memoria, quindi un utente normale, oltre a poter tranquillamente scrivere in directory di sistema, può lanciare in esecuzione dei thread che leggono e scrivono su memoria condivisa [3], [4], [5].

Faccio notare esplicitamente che su Unix a ciascun processo in esecuzione è associato l'utente che lo sta eseguendo, come si può facilmente leggere nella colonna "USER" dell'output generato (su Linux) dal comando "ps aux". Al contrario, come si può immediatamente notare lanciando il Task Manager, non sembra valere una considerazione analoga per Windows 2000... Queste considerazioni dipingono un quadro in cui architetturalmente Windows NT, al contrario di Unix, offre un modello non molto robusto di protezione del S.O. dalle azioni degli utenti... si può facilmente intuire che, per chi è abituato al rigore dei sistemi Unix, è perlomeno inquietante (o divertente... :) sapere che un utente standard può scrivere anche nelle directory di sistema e che l'amministratore di sistema non rileva l'identità (USER) con cui è in esecuzione un generico processo. Tali vulnerabilità non dipendono dai tanti bachi di Windows NT (dei quali più di 65.000 sono stati ufficialmente riconosciuti e ammessi da Microsoft nel rilasciare Windows 2000, cioè NT5... chissà quanti altri ce ne sono...): resterebbero invariate anche una volta corretti tutti gli errori di implementazione.