Sicurezza in Longhorn: attenzione al privilegio minimo

Keith Brown
SviluppoMentor

Aprile 2004

Si applica a:
   Build di anteprima "Longhorn" (Professional Developers Conference) 2003 Professional Developers Conference (PDC)

Riepilogo: Longhorn promette di essere una grande piattaforma per le applicazioni con privilegi minimi. Iniziare oggi scrivendo codice gestito, prima di tutto. Quando si compilano applicazioni desktop, renderle conformi a LUA (e usare il verificatore dell'applicazione Windows per controllare il lavoro). (11 pagine stampate)

Contenuto

Problema
Manifesti dell'applicazione e della distribuzione
LUA: Account utente con privilegi minimi
Gruppo di utenti di Power Users (deprecato)
AIM: Gestione dell'impatto dell'applicazione
PA: Amministratore protetto
Applicazioni gestite in Longhorn
Set di autorizzazioni "No Risk"
Strumenti
Riepilogo

Sono stato un sostenitore della corsa con privilegi minimi. Molti che mi conoscono hanno sentito dire che gli sviluppatori devono uscire in esecuzione con privilegi amministrativi mentre stanno sviluppando codice, se solo per incoraggiare più applicazioni a essere scritte in ambienti con privilegi minimi. Quindi sono stato molto felice di ascoltare alla conferenza di Microsoft Professional Developers Conference (PDC) del 2003 che uno degli obiettivi principali della prossima versione del sistema operativo Windows®, denominato codice "Longhorn", è semplificare l'esecuzione degli utenti con privilegi minimi.

Problema

Quando si acquista una copia di Microsoft Windows XP® Professional nel negozio software locale e la si installa in un PC, la procedura guidata di installazione crea account per te e chiunque altro che userà il computer. Dopo l'avvio di Windows XP, viene visualizzata una schermata di benvenuto che mostra il nome di ogni utente e consente loro di accedere. Ognuno di questi utenti è per impostazione predefinita un amministratore del computer. Perché? Poiché l'esperienza utente sarebbe scarsa se non fosse così.

Gli utenti si aspettano di poter installare software nei computer, ma non è possibile installare il 90% del software odierno, a meno che non si sia un amministratore. Gli utenti prevedono che il software venga eseguito senza arresto anomalo, ma il 70% del software non verrà eseguito correttamente a meno che l'utente non sia un amministratore e che sia un numero ottimistico. Purtroppo, un numero elevato di queste applicazioni non riesce in un ambiente non amministrativo semplicemente perché fanno scelte povere su dove salvare lo stato dell'applicazione. La directory File di programma non è destinata a un luogo per l'archiviazione dello stato. È un luogo per archiviare i programmi, file eseguibili. Il posto per archiviare lo stato dell'applicazione è chiamato profilo utente e per archiviare lo stato utente condiviso, il profilo "Tutti gli utenti" è sufficiente abbastanza bene. Le linee guida per il programma logo di Windows spiegano questo, ma la maggior parte del software Windows è stata sviluppata senza considerare le linee guida per il logo di Windows.

Ma perché, si potrebbe chiedere, gli utenti vogliono eseguire come non amministratori, soprattutto gli utenti domestici? Beh, se fosse effettivamente facile da fare, l'utente domestico avrebbe raccolto carichi di vantaggi. Malware (virus, worm o altro codice dannoso) ama avere privilegi amministrativi. La navigazione sul Web o la lettura di posta elettronica come amministratore è semplicemente semplice pericoloso questi giorni. Che ne dici dei tuoi figli? Non sarebbe bello consentire loro di installare e giocare giochi sul tuo computer domestico sapendo che non interromperanno accidentalmente qualcosa, installare spyware o rimuovere le limitazioni di classificazione dei contenuti che hai imposto? Pensa a questo modo: l'esecuzione come amministratore disattiva in modo efficace la maggior parte delle protezioni di sicurezza fornite da Windows. Gli utenti domestici e aziendali non dovrebbero disattivare queste protezioni, soprattutto quando si è connessi a Internet, che è diventato un quartiere piuttosto pericoloso.

Ottenere utenti e programmi eseguiti per vivere felicemente in un ambiente con privilegi minimi aumenta notevolmente la sicurezza della piattaforma Windows.

Manifesti dell'applicazione e della distribuzione

Una caratteristica importante introdotta da Longhorn è la nozione di manifesti di applicazione e distribuzione. Il primo consente agli sviluppatori di applicazioni di indicare le autorizzazioni necessarie per funzionare correttamente e quest'ultimo consente agli amministratori di specificare la quantità di attendibilità che inseriscono nell'applicazione. C'è molto di più di questo per questi manifesti, ma voglio sottolineare che sono disponibili per l'uso da parte di applicazioni gestite e non gestite, e una grande ragione per la loro esistenza è aiutare gli utenti a eseguire applicazioni con il privilegio meno possibile.

Per altre informazioni su questi manifesti, vedere il capitolo 1 del libro del Rettore Di Brent introducendo "Longhorn" per sviluppatori.

LUA: account utente Least-Privilege

LUA, o Account utente con privilegi minimi, è un acronimo che sono sicuro che venga visualizzato ripetutamente in presentazioni microsoft da ora in avanti. I relatori PDC 2003 spesso pronunciavano l'acronimo come "looah". Non c'è niente di veramente nuovo. LUA fa riferimento alla pratica dell'uso di account utente non privilegiati, sia per gli utenti interattivi che per i servizi.

Il team longhorn vuole semplificare la sicurezza. Essi ritengono che ci siano due livelli di accesso al sistema: privilegi minimi e amministrativi. Hanno anche deprecato il gruppo Power Users (noto in alcuni cerchi come "admin-lite") in Longhorn.

Con il gruppo Power Users andato, gli sviluppatori di applicazioni devono davvero fare una scelta. Devono decidere quali dei due livelli di privilegio (LUA o amministrativo) hanno bisogno dell'applicazione per Longhorn. Se l'applicazione non richiede privilegi amministrativi, deve essere scritto attentamente per funzionare con un account con privilegi minimi. Ciò significa testare (e, una speranza, anche scrivere il codice) usando gli account utente normali. Ad esempio, un'applicazione LUA deve scrivere file di dati in un luogo sicuro, ad esempio il profilo utente, anziché l'albero della directory Programmi. Ma cosa succede alle applicazioni che non vengono riscritte per Longhorn? Cosa succede se queste applicazioni non vengono eseguite bene con account con privilegi minimi anche in Windows XP? Una funzionalità longhorn denominata Application Impact Management (AIM) potrebbe essere in grado di aiutare tali app eseguite in LUA comunque, come si vedrà brevemente.

Gruppo di utenti di Power Users (deprecato)

Se si pensa a un account amministrativo con accesso "elevato" e un normale account utente con accesso "basso", un account Power User può essere detto di avere accesso "medio". Il gruppo Power Users è autorizzato a leggere e scrivere parti del file system e del Registro di sistema normalmente non consentite agli account con privilegi minimi, ovvero gli account utente normali che non mantengono l'appartenenza a gruppi con privilegi come Amministratori o Power Users. Molte persone che hanno provato a eseguire come normali utenti hanno scoperto che così tanto software ha avuto esito negativo che hanno deciso di aggiungere i propri account al gruppo Power Users, che ha risolto quasi tutti i problemi che hanno avuto. Ma non erano più in esecuzione con privilegi minimi. Ad esempio, in Windows XP, tutti i malware che vengono eseguiti con questo livello di privilegi "medio" potranno compromettere altre applicazioni archiviate nella directory Programmi, sostituire componenti COM attendibili con Trojan e così via. La prossima volta che l'utente viene eseguito con il suo account amministrativo in un computer compromesso, è possibile assicurarsi che il malware venga eseguito anche attraverso un Trojan installato in precedenza. Pertanto non si ottiene alcuna protezione reale in esecuzione come Power User.

AIM: Gestione dell'impatto dell'applicazione

Il team longhorn ritiene che l'esecuzione con privilegi minimi sia importante. Vogliono che la schermata di benvenuto contenga un elenco di account utente che sono principalmente costituiti da account con privilegi minimi. Ma hanno anche i loro piedi terra in realtà. Così come un sacco di software principale oggi ignora completamente il programma logo Windows, molto importante software nel intervallo di tempo longhorn può ignorare anche l'iniziativa LUA. Gli sviluppatori di applicazioni non elaborati continueranno a scrivere software che legge e scrive i file di dati dall'albero delle directory Programmi. Continueranno anche a scrivere dati del Registro di sistema in HKEY_LOCAL_MACHINE anziché HKEY_CURRENT_USER. Il primo è disattivato per la scrittura da parte degli utenti normali, quindi quest'ultimo è preferibile per archiviare le impostazioni dell'applicazione, se il Registro di sistema deve essere usato in tutto.

Quando Windows XP può rilevare che un'applicazione necessita di più privilegi (questo è raro, ma avviene occasionalmente con programmi di installazione), informa l'utente non con privilegi che l'applicazione richiede privilegi amministrativi per l'esecuzione, in modo pratico che venga visualizzata una finestra di dialogo per raccogliere il nome utente e la password di un account amministratore. Il programma viene quindi eseguito nell'account specificato. Ma questo non funziona sempre perché molte applicazioni non vengono scritte per essere installate in un account e usate in un altro.

Longhorn accetta un approccio completamente diverso. Anziché incoraggiare l'utente a privilegi elevati in modo che l'applicazione possa funzionare correttamente, Longhorn preferisce eseguire l'applicazione in LUA. Ma cosa accade quando l'applicazione tenta di scrivere in HKEY_LOCAL_MACHINE o nell'albero della directory Programmi? Longhorn offre all'applicazione la propria visualizzazione virtualizzata della risorsa che sta tentando di modificare, usando una strategia di copia in scrittura. Quando l'applicazione tenta di scrivere in un file nella directory Programmi, Longhorn darà all'applicazione la propria copia privata del file e può essere inserita. In questo modo, qualsiasi malware che si libera in uno scenario AIM potrebbe provare a sovrascrivere un eseguibile comunemente usato nell'albero della directory File di programma, forse WINWORD.EXE. Ma ciò che finirà per sovrascrivere è una copia privata che solo il malware può vedere. La versione di WINWORD.EXE l'utente vede sarà ancora la versione originale, non contaminata.

Non affidarsi a AIM per salvarlo. Scrivere l'applicazione da eseguire in LUA dal giorno 1.

PA: Amministratore protetto

Anche se ogni applicazione deve essere risolta nell'intervallo di tempo longhorn da eseguire in LUA, ci saranno ancora applicazioni che richiedono effettivamente privilegi amministrativi. Includono utilità come il software di backup, la deframmentazione del disco rigido e il software di suddivisione, il software di gestione aziendale e l'elenco va avanti. Quindi, a un certo punto, l'utente dovrà usare un account amministrativo per ottenere un determinato lavoro. E facciamolo, molte persone ignorano i consigli per creare account LUA e semplicemente vengono eseguiti come amministratori tutto il tempo.

Il team longhorn ha progettato uno schema ordinato per proteggere quando si esegue sotto un account amministrativo. Si tratta di una funzionalità denominata Amministratore protetto e, quando è attivata, è sempre possibile eseguire in un account amministrativo e sentirsi ragionevolmente sicuri, perché la maggior parte delle applicazioni eseguite verrà eseguita con un token con restrizioni speciale, un token simile a quello che si avrebbe in uno scenario LUA. Solo un'applicazione "benedetta" o che l'azienda è stata distribuita e designata come attendibile, verrà eseguita con il token amministrativo completo. Un modo per designare un'applicazione come attendibile consiste nel firmare il manifesto della distribuzione. Perché è utile? Permettetemi di dare un esempio.

Un utente che normalmente viene eseguito come amministratore apre il client di posta elettronica Longhorn e avvia la navigazione tramite posta elettronica. Si trova in un pezzo di posta che proviene da qualcuno che sa, e apre un allegato. Poco sa che il suo amico è stato recentemente infettato da un worm di posta elettronica e questo messaggio contiene malware. Quando il malware viene eseguito, rileva che ha un privilegio molto piccolo nel sistema. Non può modificare alcun elemento nell'albero della directory File di programma. Non può modificare le registrazioni degli oggetti COM in HKEY_LOCAL_MACHINE. Questo non è dire che non può fare niente di male, ma la situazione è un sacco di molto meglio di quanto sarebbe stato se il malware si trovasse in esecuzione con privilegi amministrativi.

Ma attendere, non ho detto che l'utente era in esecuzione come amministratore quando ha eseguito l'applicazione di posta elettronica? Sì, questo è stato in realtà il caso. Ma l'applicazione di posta elettronica non è stata designata come app di amministrazione "benedetta". infatti è stata scritta come applicazione LUA. Pertanto ha ricevuto un token con restrizioni e quindi ha fatto il malware come risultato. Questo è l'intero punto di privilegi minimi. Se si perde il controllo del sistema (forse perché si è accidentalmente eseguito un software male, o forse perché si è appena fatto clic sulla voce di menu sbagliata), il danno sarà vincolato o forse completamente impedito.

Alcuni amministratori consapevoli della sicurezza implementano già questo criterio oggi. Sono uno di loro. Ho due account, uno normale e uno amministrativo. Accedere come utente normale e passare occasionalmente all'account amministrativo quando è necessario amministrare il sistema in qualche modo, ad esempio per aggiungere una directory virtuale nel computer, creare un database in Microsoft SQL™ Server e così via. Nel caso in cui ci si chiedesse, si finisce di spendere circa il 95% del tempo in esecuzione come utente normale, anche quando si sviluppa software. Il team longhorn ha formalizzato questo approccio, un'idea spesso denominata "privilegio giusto al momento giusto" nella funzionalità Amministratore protetto (PA per breve). Ciò significa che posso solo eseguire come amministratore tutto il tempo, ma comunque essere in esecuzione con privilegi minimi. Non più passare indietro e indietro, destreggiando due profili utente e così via.

Se questo sembra un'idea ordinata e si vuole aiutare a rendere possibile che le persone usino effettivamente questa funzionalità, è necessario prendere in modo serio la scrittura di applicazioni che vengono eseguite con privilegi minimi. Poiché se questa funzionalità è abilitata, un'applicazione che richiede più privilegi di quanto sia effettivamente necessario interromperà inutilmente anche se un amministratore lo esegue, a meno che non sia stato designato come applicazione di amministratore attendibile. Naturalmente, AIM potrebbe venire in soccorso, ma non dovresti basarti su di esso, perché Microsoft stima che il 20% delle applicazioni probabilmente non sarà in grado di essere compatibile con LUA tramite AIM. Se si verifica un calo di questo 20 percento, l'applicazione non riuscirà a eseguire. Se ciò accade abbastanza, nessuno userà la funzionalità Di Amministrazione protetta e sarebbe una cosa molto triste.

Altri vantaggi emergeranno man mano che vengono scritte più applicazioni che vengono eseguite con privilegi minimi. Ad esempio, le società potranno infine bloccare le loro workstation, consentendo ai dipendenti di eseguire account con privilegi minimi. Ciò semplifica notevolmente l'amministrazione e riduce i costi. Ora è importante scrivere applicazioni che eseguono con privilegi minimi. È possibile fare una differenza su questa piattaforma.

Applicazioni gestite in Longhorn

Uno dei messaggi da PDC 2003 è che le applicazioni gestite sono il futuro. Scrivendo codice gestito, è possibile sfruttare la più recente rivoluzione nella sicurezza nella piattaforma Windows: la sicurezza tramite identità del codice. Il sistema di sicurezza basato sulle prove fornito da Common Language Runtime (CLR) e spesso definito sicurezza cas o "accesso al codice", consente al CLR di porre restrizioni aggiuntive sul codice in base a dove proviene, a chi l'ha firmato e così via. Questa dimensione aggiunta di sicurezza apre nuove strade per la distribuzione software. Eseguendo il codice in una sandbox sicura, i client possono ora eseguire il codice scaricato da un server centrale, che rende possibili funzionalità come "no touch" e "click una sola volta", riducendo ulteriormente i costi di amministrazione. E chi non preferisce un'applicazione Windows reale in esecuzione nel computer a un'applicazione basata su browser, se i rischi di distribuzione e sicurezza erano simili?

In Longhorn ogni applicazione gestita può indicare le autorizzazioni specifiche necessarie per funzionare tramite il manifesto dell'applicazione. L'elenco di codice 1 mostra un manifesto di esempio generato quando è stato creato un progetto "Longhorn Application" predefinito. Si noti la sezione TrustInfo e il set di autorizzazioni espresse. Queste sono le autorizzazioni necessarie per l'esecuzione dell'applicazione.

Elenco codici 1. Manifesto dell'applicazione

<?xml version="1.0" encoding="utf-8"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" 
manifestVersion="1.0" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="urn:schemas-microsoft-com:asm.v1 
assembly.adaptive.xsd">
  <assemblyIdentity name="MyLonghornApp" version="1.0.0.0" 
processorArchitecture="x86" asmv2:culture="en-us" 
publicKeyToken="0000000000000000" />
  <entryPoint name="main" xmlns="urn:schemas-microsoft-com:asm.v2" 
dependencyName="MyLonhornApp">
    <commandLine file="MyLonghornApp.exe" parameters="" />
  </entryPoint>
  <description asmv2:iconFile="App.ico" />
  <TrustInfo xmlns="urn:schemas-microsoft-com:asm.v2" 
xmlns:temp="temporary">
    <Security>
      <ApplicationRequestMinimum>
        <PermissionSet class="System.Security.PermissionSet" 
version="1" ID="SeeDefinition">
          <IPermission 
class="System.Security.Permissions.FileDialogPermission" version="1" 
Unrestricted="true" />
          <IPermission class="System.Security.Permissions.IsolatedStorageFilePermission" 
version="1" Allowed="DomainIsolationByUser" UserQuota="5242880" />
          <IPermission 
class="System.Security.Permissions.SecurityPermission" version="1" 
Flags="Execution" />
          <IPermission class="System.Security.Permissions.UIPermission" 
version="1" Window="SafeTopLevelWindows" Clipboard="OwnClipboard" />
          <IPermission 
class="System.Drawing.Printing.PrintingPermission, System.Drawing, 
Version=1.2.3400.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" 
version="1" Level="SafePrinting" />
          <IPermission class="MSAvalon.Windows.AVTempUIPermission, 
PresentationFramework, Version=6.0.4030.0, Culture=neutral, 
PublicKeyToken=a29c01bbd4e39ac5" version="1" 
NewWindow="LaunchNewWindows" FullScreen="SafeFullScreen" />
        </PermissionSet>
        <DefaultAssemblyRequest PermissionSetReference="SeeDefinition" 
/>
      </ApplicationRequestMinimum>
    </Security>
  </TrustInfo>
  <dependency asmv2:name="MyLonghornApp">
    <dependentAssembly>
      <assemblyIdentity name="MyLonghornApp" version="0.0.0.0" 
processorArchitecture="x86" />
    </dependentAssembly>
    <asmv2:installFrom codebase="MyLonghornApp.exe" 
hash="28c18a303c7fb7e9fe43a32b456f0932f52125a9" hashalg="SHA1" 
size="110592" />
  </dependency>
</assembly>

Un'applicazione gestita conforme a LUA includerà sempre una sezione simile a questa e il responsabile trust in Longhorn userà queste informazioni per determinare se consentire l'installazione dell'applicazione nel computer. Se l'applicazione viene codificata con attenzione, può essere in grado di eseguire con privilegi così bassi che il gestore attendibilità può assegnarlo un punteggio di "nessun rischio" e l'applicazione può essere installata immediatamente ed eseguita senza intervento dell'utente. Tuttavia, se l'applicazione assegna un punteggio di rischio più pericoloso in base alle autorizzazioni richieste, l'utente verrà richiesto con una finestra di dialogo che descrive i potenziali pericoli che l'applicazione pone. L'utente può quindi scegliere se consentire l'installazione e l'esecuzione dell'applicazione.

Dichiarando le proprie intenzioni davanti al manifesto è una buona idea, perché se non si è, il responsabile attendibilità può solo assumere il peggiore rispetto all'applicazione e la classificazione dei rischi espressa all'utente sembrerà tutto più sinister. È quindi consigliabile esprimere le autorizzazioni necessarie nel manifesto. Non ignorare questo passaggio,

In uno studio menzionato in PDC 2003, Microsoft ha rilevato che il 40% degli utenti fa sempre clic su "No" quando viene visualizzata una finestra di dialogo di sicurezza, ad esempio gli avvisi di download del controllo ActiveX. È chiaro che se si vuole distribuire il software agli utenti tramite Internet, si spera di ottenere una classificazione di rischio "nessun rischio" dal responsabile attendibilità in Longhorn, quindi l'utente non verrà richiesto prima di installare ed eseguire l'applicazione. Si potrebbe quindi chiedersi se esiste un set documentato di autorizzazioni che saranno sempre segnate "nessun rischio". Si scopre che esiste una definizione di questo tipo ed è noto come set di autorizzazioni SEE.

Set di autorizzazioni "No Risk"

Si potrebbe aver sentito questo fatto riferimento a PDC 2003 come SEE (Secure Execution Environment), ma la maggior parte delle persone trova il termine piuttosto confuso, quindi chiamerò semplicemente questo set di autorizzazioni senza rischi. Longhorn verrà fornito con un set di autorizzazioni speciale che segna sempre "nessun rischio" con il gestore di attendibilità predefinito in Longhorn. Se si scrive un'applicazione i cui requisiti di autorizzazione rientrano interamente all'interno del set di autorizzazioni senza rischi, può essere installato ed eseguito senza visualizzare avvisi di attendibilità. Il codice concesso solo all'interno di questo set (almeno come definito inizialmente da Microsoft) non deve essere in grado di danneggiare il computer intenzionalmente o accidentalmente.

Quindi, se si vuole che l'applicazione venga installata ed eseguita senza che l'utente venga richiesto con una finestra di dialogo spaventosa, si vuole limitare le attività consentite da questo set di autorizzazioni. È consigliabile sapere che il team di Longhorn sta valutando la possibilità di configurare questo set di autorizzazioni da parte degli amministratori, pertanto ciò che viene considerato "nessun rischio" in un sito potrebbe essere diverso in un altro. Ma per la maggior parte delle installazioni longhorn, il set di autorizzazioni no-risk sarà quello predefinito che viene fornito con il sistema operativo.

Cosa sembra? Esaminare il manifesto nell'elenco di codice 1. Si noti l'ID specificato al Set di autorizzazioni definito nella sezione TrustInfo, "SeeDefinition".

Ecco l'aspetto del set di autorizzazioni senza rischio per la compilazione di anteprima PDC 2003: FileDialogPermission senza restrizioni consente di leggere o scrivere file dell'utente scegliendo tramite le classi OpenFileDialog e SaveFileDialog standard, ma non è consentito imparare nulla sulla struttura del file system dell'utente, incluso il nome del file scelto dall'utente. IsolatedStoragePermission consente a un assembly di leggere e scrivere fino a 5 megabyte di stato specifico dell'utente sul disco rigido dell'utente senza dover richiederle una finestra di dialogo di file. SecurityPermission consente all'esecuzione del codice al primo posto. UiPermission consente di disegnare sullo schermo, ma solo nelle proprie finestre e concede l'accesso limitato agli Appunti (non è possibile leggere il contenuto a livello di codice, ma l'utente può incollare dagli Appunti nei controlli). PrintingPermission consente di stampare, ma solo se lo si esegue tramite la finestra di dialogo di stampa. Il codice non può avviare in modo automatico i processi di stampa senza che l'utente lo sappia. L'autorizzazione "Avalon" specifica consente al codice di creare finestre a schermo intero purché abbiano un bordo controllato dal sistema operativo (quindi non è possibile spoofare la schermata di accesso, ad esempio).

Tenere presente che questa definizione cambierà quasi certamente nel tempo; può anche cambiare prima delle navi beta longhorn. Quindi prendi la mia descrizione qui con una grana di sale. Si spera che questo articolo contribuirà a motivare l'utente a esaminare alcune delle funzionalità con privilegi minimi in .NET Framework, ad esempio l'archiviazione isolata e i dialoghi comuni, perché la definizione finale del set di autorizzazioni senza rischi richiederà molto probabilmente di usare queste funzionalità per evitare una finestra di dialogo di attendibilità.

La definizione di un set di autorizzazioni senza rischi non è un'attività semplice. Il team longhorn sa che se la sua definizione è troppo restrittiva, non sarà possibile usarla abbastanza applicazioni. Ma se è troppo permissivo, il malware lo usi sicuramente. Si spera che la squadra possa trovare il punto dolce. La figura 1 è un diagramma che mostra l'intervallo di privilegi per le applicazioni Longhorn, da un'applicazione amministratore benedetta fino alle applicazioni progettate per l'esecuzione con il set di autorizzazioni SEE.

Figura 1. Tipi di applicazioni

Strumenti

La creazione di applicazioni con privilegi minimi non è mai stata semplice. È necessario avere linee guida e strumenti da aiutare. Sono stati illustrati alcuni esempi di questi strumenti in PDC 2003, il primo dei quali è Visual Studio® 2005 (codice denominato "Whidbey" nell'intervallo di tempo PDC 2003).

Questo nuovo ambiente di sviluppo offre numerose funzionalità che consentono di facilitare la destinazione di un ambiente con privilegi minimi. Ad esempio, è possibile scegliere un set di autorizzazioni che si vuole applicare quando si esegue il debug dell'applicazione. Un ottimo posto per iniziare per le applicazioni Longhorn sarebbe il set di autorizzazioni SEE. Per le applicazioni esistenti, la scommessa migliore consiste nell'indirizzare il set di autorizzazioni Internet, che è piuttosto vicino al modo in cui è definito oggi il see.

Dopo aver avviato il debug con autorizzazioni ridotte, è necessario eseguire alcune operazioni di sicurezza impreviste. La figura 2 mostra un esempio classico in cui lo sviluppatore usa una finestra di dialogo di file per richiedere all'utente un nome file e quindi tenta di leggere il nome file specificato. Se si concede FileDialogPermission (come si è nel set di autorizzazioni SEE), che consente di richiedere all'utente un file, ma in particolare non è consentito visualizzare il nome file selezionato dall'utente. È invece necessario chiamare un metodo (OpenFile) per aprire un flusso che è quindi possibile usare per leggere dal file. Visual Studio 2005 fornisce consigli per aiutare lo sviluppatore a trovare il modo corretto per usare la classe OpenFileDialog per evitare l'eccezione di sicurezza.

Figura 2. Supporto migliore degli strumenti

Un altro strumento utile annunciato a PDC 2003 è chiamato PermCalc. Si tratta di uno strumento della riga di comando che valuta un assembly e determina tramite euristica le autorizzazioni necessarie per l'esecuzione. Questa funzionalità è prevista anche per l'inclusione in Visual Studio 2005. Questo è un ottimo modo per indirizzare gli ambienti con privilegi minimi. Uno strumento simile che esiste oggi è denominato verifica applicazione Windows, parte di Windows Application Compatibility Toolkit. Questo strumento consente di rilevare quando l'applicazione viola le regole, ad esempio la scrittura in parti protette del file system o del Registro di sistema.

Riepilogo

Longhorn promette di essere una grande piattaforma per le applicazioni con privilegi minimi. Iniziare oggi scrivendo codice gestito, prima di tutto. Quando si creano applicazioni desktop, renderle conformi a LUA (e usare il verificatore dell'applicazione Windows per controllare il lavoro). Se è possibile, indirizzare il set di autorizzazioni Internet per il momento e sarà probabilmente adatto a SEE quando Longhorn viene fornito.

Ulteriori informazioni

Leggere il libro del Rettore Di Brent, introduzione a "Longhorn" per sviluppatori.

Informazioni sull'autore

Keith Brown è un consulente indipendente specializzato nella sicurezza delle applicazioni. Ha creato il libro Programmazione Sicurezza di Windows (Addison-Wesley, 2000) e sta scrivendo un nuovo libro di sicurezza per i programmatori .NET. Leggere il nuovo libro online all'indirizzo http://www.develop.com/kbrown.