Autore: PUOJACKZ Data: 2005-11-24 Modificato: Documento non modificato Letture: 389 Torna indietro

Una delle prime considerazioni, riguardo la pianificazione della politica di sicurezza, in un sistema multiutente, è quella di creare vari account con privilegi limitati, al fine di ridurre eventuali problemi, qualora un malware acceda al sistema e riesca ad attivarsi. Anche se il box da configurare è destinato nell'essere e rimanere una postazione stand-alone.
Infatti, eseguire programmi, oppure, navigare nel Web, con privilegi d'accesso massimali (impostati, in modalità predefinita, nell'account Administrator), può recare, col tempo, effetti indesiderati. La situazione s'inasprisce ulteriormente qualora, durante l'escalation silente in atto, vengano coinvolti eventuali dati sensibili importanti della propria vita quotidiana, o per la professione lavorativa, senza aver, preventivamente, disposto una pianificazione di backup.
Purtroppo, però, occorre tener presente alcune considerazioni vincolanti.
Nei sistemi operativi quali UNIX e derivati (es. Linux), fin dagli albori, l'ambiente dell'utente era vincolato da dei permessi di scrittura, lettura ed esecuzione, implementati a livello nativo, nell'OS. Inoltre, il sistema, provvedeva, con vari stratagemmi (es. documentazione, messaggi popup, imposizioni nell'installazione degli applicativi ecc.), nel sensibilizzare, chi lo usava, degli eventuali rischi potenziali derivanti dalla mancata osservazione delle norme di sicurezza presenti.
Nei laboratori di sviluppo dei software, tali capisaldi venivano (e vengono tutt'ora) osservati rigidamente, creando un accomodamento di quanto veniva prodotto, con il sistema di protezione a diritti d'interazione presenti nell'OS.
In ambienti Microsoft, disgraziatamente, tale pianificazione operativa può trovar accoglimento solo in tutti quegli applicativi creati per essere eseguiti in sistemi NT (e totalmente incompatibili con le tecnologie implementate in Win95/98 ed ME). Siccome l'impiego di WinNT, in passato, implicava certe particolari conoscenze d'informatica, nelle imprese medio-piccole, così come nei box casalinghi, era più conveniente adottare soluzioni più semplici, che permettessero, allo stesso tempo, una vasta scelta di applicativi, su cui poter far affidamento. Ciò, ha condotto il mercato del software nel sviluppare programmi, NT-compliant, solo per certi ambienti particolari, mentre, la fetta più grossa, era dedicata a sistemi Win9x, i quali, non erano MINIMAMENTE basati su concetti di sicurezza nativa ad impostazione di privilegio.
Ovviamente, tali applicativi, in fase di esecuzione, ottenevano diritti d'accesso arbitrari.
Con l'avvento di Windows XP, è stata aggiunta la possibilità di eseguire anche programmi per ambienti Win9x, i quali, non sarebbero mai stati importati su OS con tecnologia NT. Ciò ha risolto non pochi grattacapi alle case di software, in quanto, un eventuale attività di "porting", avrebbe comportato la riscrizione TOTALE di interi programmi (a causa della differente metodologia di accesso alle periferiche I/O, alle aree di memoria ecc., presenti sul sistema a Kernel monolitico NT).
Inoltre, avrebbe comportato l'ipotetica introduzione di eventuali errori aggiuntivi nel codice, oltre al generico dispendio di tempo e soldi per un "qualcosa" già prodotto.
Per l'utenza casalinga, il funzionamento di certi applicativi, creati, inizialmente, per esser eseguiti in ambienti Win9x, richiederebbe un account con accesso massimale (es. Administrator), rendendo inutile l'impostazione dei criteri di protezione.
Un sistema per aggirare questo difetto sarebbe quello di sensibilizzare i newbie nell'usare degli account limitati e, qualora vi fosse la necessità di eseguire del software non NT-Compliant, sfruttare l'opzione "Esegui Come" (Run As), disponibile sia come voce nel menù di servizio offerto dal sistema (quello che appare premendo il pulsante destro del mouse, dopo aver selezionato un file eseguibile), sia come comando disponibile dalla Shell di MS-DOS (sotto il nome di "RUNAS"). Questa permetterebbe di specificare un maggior privilegio d'azione, localmente solo all'eseguibile coinvolto, senza esporsi ad inutili rischi.

Cosa comporta l'uso di un Account non Administrator, su un programma non NT?

Qualora un utente tenti di eseguire un programma creato per ambienti non NT, su un account non dotato di privilegi massimali, possono manifestari vari tipi di errore, alcuni banali, altri, invece, gravi (che comportano il malfunzionamento del software stesso). Può accadere che:

* Il programma non venga eseguito (neanche con la modalità di compatibilità attiva)
* Si manifestino dei crash inaspettati, quando, invece, le stesse routines, su ambienti Win9x funzionavano perfettamente
* Vengano generati degli errori a 32-bit (es. di run-time), durante l'esecuzione
* Alcune particolarità del programma (es. suoni, oppure, input da tastiera) generino dei malfunzionamenti che, successivamente, sfociano in attività anormali, inceppamenti casuali, errori sconosciuti, oppure, talmente gravi da non poter esser corretti adattando le impostazioni dell'applicativo
* I software non riconoscano, inaspettatamente, dei componenti o delle attività legate all'hardware, più o meno importanti
* Il programma è in uno stato di malfunzionamento tale da non permettere il salvataggio, l'apertura o la modifica dei files
* Il programma diventa instabile da richiedere la terminazione forzata, come unica opzione per lo spegnimento
* Il programma diventa instabile, andando ad occupare erroneamente delle funzioni dell'OS, che non vengono liberate neppure in caso di terminazione forzata