Sécurité à Longhorn : focus sur les privilèges minimum

 

Keith Brown
DevelopMentor

Avril 2004

S’applique à :
   2003 Professional Developers Conference (PDC) build « Longhorn » preview

Résumé: Longhorn promet d’être une excellente plateforme pour les applications avec privilèges minimum. Commencez dès aujourd’hui en écrivant du code managé, tout d’abord. Lors de la création d’applications de bureau, rendez-les conformes À LUA (et utilisez le vérificateur d’applications Windows pour vous aider à case activée votre travail). (11 pages imprimées)

Contenu

Le problème
Manifestes d’application et de déploiement
LUA : Compte d’utilisateur avec privilège minimum
Groupe Utilisateurs avec pouvoir (déconseillé)
AIM : Gestion de l’impact des applications
PA : Administrateur protégé
Applications managées sur Longhorn
Jeu d’autorisations « Sans risque »
Outils
Résumé

J’ai longtemps été un partisan de la course avec les privilèges minimum. Beaucoup de ceux qui me connaissent ont entendu dire que les développeurs devraient cesser de s’exécuter avec des privilèges d’administration pendant qu’ils développent du code, ne serait-ce que pour encourager davantage d’applications à être écrites pour s’exécuter dans des environnements à privilèges minimum. J’ai donc été très heureux d’apprendre lors de la conférence Microsoft Professional Developers (PDC) 2003 que l’un des objectifs main de la prochaine version du système d’exploitation Windows®, nommée « Longhorn », est de faciliter l’exécution des utilisateurs avec les privilèges minimum.

Le problème

Lorsque vous achetez une copie de Microsoft Windows XP® Professionnel dans votre magasin de logiciels local et que vous l’installez sur un PC, l’Assistant d’installation crée des comptes pour vous et toute autre personne qui utilisera l’ordinateur. Une fois windows XP démarré, il affiche un écran d’accueil qui affiche le nom de chaque utilisateur et lui permet de se connecter. Chacun de ces utilisateurs est par défaut un administrateur de l’ordinateur. Pourquoi ? Parce que l’expérience utilisateur serait médiocre si ce n’était pas de cette façon.

Les utilisateurs s’attendent à pouvoir installer des logiciels sur leurs ordinateurs, mais vous ne pouvez pas installer 90 % des logiciels actuels, sauf si vous êtes administrateur. Les utilisateurs s’attendent à ce que les logiciels s’exécutent sans se bloquer, mais 70 % des logiciels ne s’exécutent pas correctement, sauf si l’utilisateur est un administrateur, et c’est un nombre optimiste. Malheureusement, un grand nombre de ces applications échouent dans un environnement non administratif simplement parce qu’elles font de mauvais choix quant à l’emplacement où enregistrer l’état de l’application. Le répertoire Program Files n’est pas destiné à stocker l’état. Il s’agit d’un emplacement pour stocker des programmes, c’est-à-dire des fichiers exécutables. L’emplacement où stocker l’état de l’application est appelé profil utilisateur, et pour stocker l’état utilisateur partagé, le profil « Tous les utilisateurs » suffit très bien. Les instructions du programme de logo Windows expliquent cela, mais la grande majorité des logiciels Windows ont été développés aujourd’hui sans tenir compte des instructions relatives aux logo Windows.

Mais pourquoi, demandez-vous, les utilisateurs doivent-ils vouloir s’exécuter en tant que non-administrateurs, en particulier les utilisateurs à domicile ? Eh bien, si c’était vraiment facile à faire, l’utilisateur à domicile récolterait beaucoup d’avantages. Les programmes malveillants (virus, ver ou autre code malveillant) aiment avoir des privilèges d’administration. Naviguer sur le Web ou lire des e-mails en tant qu’administrateur est tout simplement dangereux de nos jours. Qu’en est-il de vos enfants ? Ne serait-il pas agréable de leur permettre d’installer et de jouer à des jeux sur votre ordinateur personnel sachant qu’ils ne casseront pas accidentellement quelque chose, installer des logiciels espions, ou supprimer les limitations d’évaluation du contenu que vous avez imposées? Pensez-y de cette façon : l’exécution en tant qu’administrateur désactive efficacement la plupart des protections de sécurité fournies par Windows. Les particuliers et les entreprises ne devraient pas désactiver ces protections, en particulier lorsqu’ils sont connectés à Internet, qui est devenu un quartier plutôt dangereux.

Permettre aux utilisateurs et aux programmes qu’ils exécutent de vivre heureux dans un environnement de privilèges minimum va considérablement augmenter la sécurité de la plateforme Windows.

Manifestes d’application et de déploiement

Une fonctionnalité importante introduite par Longhorn est la notion de manifestes d’application et de déploiement. La première permet aux développeurs d’applications d’indiquer les autorisations dont leur application a besoin pour fonctionner correctement, et la seconde permet aux administrateurs de spécifier le niveau de confiance qu’ils placent dans l’application. Il y a beaucoup plus que cela dans ces manifestes, mais je tiens à souligner qu’ils sont disponibles pour une utilisation par les applications managées et non managées, et qu’une grande raison de leur existence est d’aider les utilisateurs à exécuter des applications avec le moins de privilèges possible.

Pour en savoir plus sur ces manifestes, consultez le chapitre 1 du livre de Brent Rector Introducing « Longhorn » for Developers.

LUA : compte d’utilisateur Least-Privilege

LUA, ou Compte d’utilisateur à privilèges minimum, est un acronyme, je suis sûr que vous verrez plusieurs fois dans les présentations Microsoft à partir de maintenant. Les présentateurs du PDC 2003 ont souvent prononcé l’acronyme « looah ». Ce n’est rien d’extraordinaire, pas même quelque chose de vraiment nouveau. LUA fait référence à la pratique d’utiliser des comptes d’utilisateur sans privilèges, à la fois pour les utilisateurs interactifs et pour les services.

L’équipe Longhorn souhaite simplifier la sécurité. Ils croient qu’il devrait y avoir deux niveaux d’accès au système : le privilège minimum et l’accès administratif. Ils ont même déprécié le groupe Utilisateurs avec pouvoir (appelé « admin-lite » dans certains cercles) dans Longhorn.

Avec le groupe Utilisateurs avec pouvoir disparu, les développeurs d’applications doivent vraiment faire un choix. Ils doivent décider des deux niveaux de privilège (LUA ou administratif) dont leur application a besoin pour Longhorn. Si l’application n’a pas besoin de privilèges administratifs, elle doit être écrite avec soin pour fonctionner sous un compte à privilèges minimum. Cela signifie tester (et, espérons-le, même écrire le code) à l’aide de comptes d’utilisateur normaux. Par exemple, une application LUA doit écrire des fichiers de données dans un endroit sûr, tel que le profil utilisateur, par opposition à l’arborescence du répertoire Program Files. Mais qu’advient-il des applications qui ne sont pas réécrites pour Longhorn ? Que se passe-t-il si ces applications ne s’exécutent pas correctement sous les comptes de privilèges minimum, même sur Windows XP ? Une fonctionnalité longhorn appelée Application Impact Management (AIM) peut être en mesure d’aider ces applications à s’exécuter sous LUA, comme vous le verrez sous peu.

Groupe Utilisateurs avec pouvoir (déconseillé)

Si vous pensez qu’un compte d’administration dispose d’un accès « élevé » et qu’un compte d’utilisateur normal dispose d’un accès « faible », un compte Power User peut être considéré comme ayant un accès « moyen ». Le groupe Utilisateurs avec pouvoir est autorisé à lire et à écrire des parties du système de fichiers et du Registre qui sont normalement interdites aux comptes à privilèges minimum (c’est-à-dire les comptes d’utilisateurs normaux qui ne sont pas membres de groupes privilégiés tels que administrateurs ou utilisateurs avec pouvoir). De nombreuses personnes qui ont essayé d’exécuter en tant qu’utilisateurs normaux ont constaté que tant de logiciels ont échoué qu’elles ont décidé d’ajouter leurs comptes au groupe Utilisateurs avec pouvoir, ce qui a résolu presque tous les problèmes qu’ils rencontraient. Mais ils ne fonctionnaient plus vraiment avec le moindre privilège. Par exemple, sur Windows XP, tout programme malveillant qui s’exécute avec ce niveau de privilège « moyen » est autorisé à compromettre d’autres applications stockées dans le répertoire Program Files, à remplacer les composants COM approuvés par des chevaux de Troie, etc. La prochaine fois que l’utilisateur s’exécute sous son compte d’administration sur un ordinateur compromis, vous pouvez être sûr que le programme malveillant s’exécutera également via un cheval de Troie précédemment installé. Par conséquent, vous n’obtenez aucune protection réelle s’exécutant en tant qu’utilisateur power.

AIM : Gestion de l’impact des applications

L’équipe de Longhorn croit qu’il est important de courir avec le moindre privilège. Ils veulent que cet écran d’accueil contienne une liste de comptes d’utilisateur qui se compose principalement de comptes avec privilèges minimum. Mais ils ont aussi les pieds ancrés dans la réalité. Tout comme beaucoup de logiciels majeurs aujourd’hui ignorent complètement le programme de logo Windows, beaucoup de logiciels majeurs dans la période Longhorn peuvent également ignorer l’initiative LUA. Les développeurs d’applications non informés continueront à écrire des logiciels qui lisent et écrivent des fichiers de données à partir de l’arborescence du répertoire Program Files. Ils continueront également à écrire des données de Registre dans HKEY_LOCAL_MACHINE au lieu de HKEY_CURRENT_USER. Le premier étant hors limites pour l’écriture par les utilisateurs normaux, le second est préférable pour stocker les paramètres d’application, si le Registre doit être utilisé du tout.

Lorsque Windows XP peut détecter qu’une application a besoin de plus de privilèges (ce qui est rare, mais se produit occasionnellement avec les programmes d’installation), il informe l’utilisateur non privilégié que l’application a besoin de privilèges administratifs pour s’exécuter, en affichant commodément une boîte de dialogue pour collecter le nom d’utilisateur et le mot de passe d’un compte administrateur. Le programme s’exécute ensuite sous le compte spécifié. Mais cela ne fonctionne pas toujours, car de nombreuses applications ne sont pas écrites pour être installées sous un compte et utilisées sous un autre.

Longhorn adopte une approche complètement différente. Au lieu d’encourager l’utilisateur à élever les privilèges afin que l’application puisse fonctionner correctement, Longhorn préfère exécuter l’application sous LUA. Mais que se passe-t-il lorsque l’application tente d’écrire dans HKEY_LOCAL_MACHINE ou l’arborescence du répertoire Program Files ? Longhorn donne à l’application sa propre vue virtualisée de la ressource qu’elle tente de modifier, à l’aide d’une stratégie de copie sur écriture. Lorsque l’application tente d’écrire dans un fichier dans le répertoire Program Files, Longhorn lui donne sa propre copie privée du fichier et peut en faire partie. De cette façon, tout programme malveillant qui se perd dans un scénario AIM peut essayer de remplacer un exécutable couramment utilisé sous l’arborescence du répertoire Program Files, peut-être WINWORD.EXE. Mais ce qu’il finira par remplacer est une copie privée que seul le programme malveillant peut voir. La version de WINWORD.EXE l’utilisateur voit toujours la version d’origine non conservée.

Ne comptez pas sur AIM pour vous sauver. Écrivez votre application pour qu’elle s’exécute sous LUA dès le premier jour.

PA : Administrateur protégé

Même si chaque application devait être corrigée dans la période Longhorn pour s’exécuter sous LUA, il y aura toujours des applications qui nécessitent vraiment des privilèges d’administration. Ils incluent des utilitaires tels que les logiciels de sauvegarde, les logiciels de défragmentation et de repartitionnement de disque dur, les logiciels de gestion d’entreprise, et la liste continue. Par conséquent, à un moment donné, l’utilisateur devra utiliser un compte d’administration pour effectuer certains travaux. Et avouons-le, beaucoup de gens ignorent les conseils de créer des comptes LUA et s’exécutent simplement en tant qu’administrateurs tout le temps.

L’équipe longhorn a conçu un schéma soigné pour vous protéger lorsque vous exécutez sous un compte d’administration. Il s’agit d’une fonctionnalité appelée Administrateur protégé, et quand elle est activée, vous pouvez toujours exécuter sous un compte d’administration et vous sentir raisonnablement en sécurité, car la grande majorité des applications que vous exécutez seront exécutées avec un jeton restreint spécial, un jeton similaire à ce que vous auriez dans un scénario LUA. Seule une application que vous avez « bénie » ou que votre entreprise a déployée et désignée comme approuvée s’exécute avec votre jeton d’administration complet. Une façon de désigner une application comme approuvée consiste à signer son manifeste de déploiement. Pourquoi cette option est-elle utile ? Permettez-moi de vous donner un exemple.

Un utilisateur qui s’exécute normalement en tant qu’administrateur ouvre son client de messagerie Longhorn et commence à parcourir le courrier électronique. Elle tombe sur un courrier provenant de quelqu’un qu’elle connaît et ouvre une pièce jointe. Elle ne sait pas que son ami a récemment été infecté par un ver de messagerie, et ce message contient des programmes malveillants. Lorsque le programme malveillant s’exécute, il constate qu’il a très peu de privilèges sur le système. Il ne peut rien modifier dans l’arborescence du répertoire Program Files. Il ne peut pas modifier les inscriptions d’objets COM sous HKEY_LOCAL_MACHINE. Ce n’est pas pour dis-le ne peut rien faire de mal, mais la situation est un peu mieux qu’elle aurait été si le programme malveillant s’est trouvé s’exécuter avec des privilèges d’administration.

Mais attendez, n’ai-je pas dit que l’utilisateur s’exécutait en tant qu’administrateur quand il a exécuté l’application de messagerie ? Oui, c’était en fait le cas. Mais l’application de messagerie n’a pas été désignée comme une application d’administration « bénie » ; en fait, il a été écrit sous la forme d’une application LUA. Ainsi, il a reçu un jeton restreint, et le programme malveillant en conséquence. C’est tout le point du moindre privilège. Si vous perdez le contrôle du système (peut-être parce que vous avez accidentellement exécuté un logiciel maléfique, ou peut-être parce que vous venez de cliquer sur le mauvais élément de menu), les dommages seront limités ou peut-être complètement empêchés.

Certains administrateurs soucieux de la sécurité implémentent déjà cette stratégie aujourd’hui. Je suis l’un d’eux. J’ai deux comptes, un compte normal et un compte administratif. Je me connecte en tant qu’utilisateur normal et passe parfois à mon compte d’administration lorsque j’ai besoin d’administrer mon système d’une manière ou d’une autre, pour instance d’ajouter un répertoire virtuel sur mon ordinateur, de créer une base de données dans Microsoft SQL™ Server, etc. (Au cas où vous vous demandiez, je finis par passer environ 95% de mon temps à courir en tant qu’utilisateur normal, même lors du développement de logiciels.) L’équipe de Longhorn a formalisé cette approche, une idée souvent appelée « privilège approprié au bon moment » dans la fonctionnalité Administrateur protégé (PA, en abrégé). Cela signifie que je peux simplement exécuter en tant qu’administrateur tout en continuant à être en cours d’exécution avec les privilèges minimum. Plus de va-et-vient, de jongler entre deux profils utilisateur, et ainsi de suite.

Si cela semble être une idée soignée, et que vous souhaitez aider à permettre aux utilisateurs d’utiliser réellement cette fonctionnalité, vous devrez prendre au sérieux l’écriture d’applications qui s’exécutent avec le moindre privilège. En effet, si cette fonctionnalité est activée, une application qui nécessite plus de privilèges qu’elle n’en a réellement besoin s’interrompt inutilement même si un administrateur l’exécute, sauf si elle a été désignée en tant qu’application d’administration approuvée. Bien sûr, AIM peut venir à votre secours, mais vous ne devez pas compter sur elle, car Microsoft estime que 20 % des applications ne pourront probablement pas être rendues compatibles LUA via AIM. Si vous tombez dans ces 20 %, votre application ne pourra pas s’exécuter. Si cela se produit suffisamment, personne n’utilisera la fonctionnalité Administration protégé, et ce serait une chose très triste en effet.

D’autres avantages émergent à mesure que de plus en plus d’applications sont écrites qui s’exécutent avec les privilèges minimum. Par exemple, les entreprises pourront enfin verrouiller leurs stations de travail, ce qui permet aux employés d’exécuter des comptes avec des privilèges minimum. Cela simplifiera considérablement l’administration et réduira les coûts. Plus que jamais, il est important d’écrire des applications qui s’exécutent avec des privilèges minimum. Vous pouvez faire une différence sur cette plateforme.

Applications managées sur Longhorn

L’un des messages de PDC 2003 était que les applications managées sont l’avenir. En écrivant du code managé, vous pouvez tirer parti de la dernière révolution en matière de sécurité sur la plateforme Windows : la sécurité via l’identité de code. Le système de sécurité basé sur des preuves fourni par le Common Language Runtime (CLR) et souvent appelé « sécurité d’accès au code », permet au CLR d’appliquer des restrictions supplémentaires sur le code en fonction de son provenance, de la personne qui l’a signé, etc. Cette dimension de sécurité supplémentaire ouvre de nouvelles voies pour la distribution de logiciels. En exécutant du code dans un bac à sable sécurisé, les clients peuvent désormais exécuter en toute confiance le code téléchargé à partir d’un serveur central, ce qui rend possible des fonctionnalités telles que le déploiement « sans interaction tactile » et « clic une fois », ce qui réduit davantage les coûts d’administration. Et qui ne préférerait pas une application Windows réelle s’exécutant sur son ordinateur à une application basée sur un navigateur, si les risques de déploiement et de sécurité étaient similaires ?

Dans Longhorn, chaque application managée peut indiquer les autorisations spécifiques dont elle a besoin pour fonctionner via le manifeste de l’application. La liste de code 1 montre un exemple de manifeste généré lorsque j’ai créé un projet « Application Longhorn » généré par l’Assistant par défaut. Notez la section TrustInfo et l’ensemble d’autorisations qui y sont exprimées. Il s’agit des autorisations dont l’application a besoin pour s’exécuter.

Code Listing 1. Manifeste d’application

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

Une application managée compatible LUA inclut toujours une section comme celle-ci, et le gestionnaire d’approbations de Longhorn utilise ces informations pour déterminer s’il faut autoriser l’installation de l’application sur l’ordinateur. Si l’application est codée avec soin, elle peut être en mesure de s’exécuter avec des privilèges si faibles que le gestionnaire de confiance peut lui attribuer un score « sans risque », et l’application peut être installée immédiatement et exécutée sans intervention de l’utilisateur. Toutefois, si l’application note une note de risque plus dangereuse en fonction des autorisations qu’elle demande, l’utilisateur est invité à entrer une boîte de dialogue décrivant les dangers potentiels que pose l’application. L’utilisateur peut ensuite choisir d’autoriser l’installation et l’exécution de l’application.

Il est judicieux d’indiquer vos intentions à l’avance dans le manifeste, car si vous ne le faites pas, le gestionnaire de confiance ne peut qu’assumer le pire de votre application, et la cote de risque exprimée à l’utilisateur semblera d’autant plus sinistre. Il est donc judicieux d’exprimer les autorisations dont vous avez besoin dans votre manifeste. N’ignorez pas cette étape.

Dans une étude mentionnée au PDC 2003, Microsoft a constaté que 40 % des utilisateurs cliquent toujours sur « Non » lorsqu’ils présentaient des boîtes de dialogue de sécurité telles que des avertissements de téléchargement de contrôle ActiveX. Il est clair que si vous souhaitez distribuer votre logiciel aux utilisateurs sur Internet, vous espérez que le gestionnaire de confiance de Longhorn ne sera pas invité à l’utiliser avant d’installer et d’exécuter votre application. Par conséquent, vous vous demandez peut-être s’il existe un ensemble documenté d’autorisations qui sera toujours noté « sans risque ». Il s’avère qu’il existe une telle définition et qu’elle est appelée jeu d’autorisations SEE.

Jeu d’autorisations « Sans risque »

Vous avez peut-être entendu parler de cela dans PDC 2003 sous le nom SEE (Secure Execution Environment), mais la plupart des gens trouvent ce terme plutôt confus, donc je vais simplement appeler cela le jeu d’autorisations sans risque. Longhorn sera fourni avec un jeu d’autorisations spécial qui marquera toujours « aucun risque » avec le gestionnaire d’approbation par défaut dans Longhorn. Si vous écrivez une application dont les exigences en matière d’autorisation sont entièrement comprises dans le jeu d’autorisations sans risque, vous pouvez l’installer et l’exécuter sans afficher d’avertissements de confiance. Le code disposant d’autorisations uniquement dans ce jeu (du moins tel qu’il est défini initialement par Microsoft) ne doit pas être en mesure d’endommager votre machine intentionnellement ou accidentellement.

Par conséquent, si vous souhaitez que votre application s’installe et s’exécute sans que l’utilisateur soit invité à entrer une boîte de dialogue effrayante, vous devez vous limiter aux activités autorisées par ce jeu d’autorisations. Vous devez savoir que l’équipe Longhorn envisage de rendre ce jeu d’autorisations configurable par les administrateurs. Par conséquent, ce qui est considéré comme « sans risque » sur un site peut être différent à un autre. Toutefois, pour la grande majorité des installations de Longhorn, le jeu d’autorisations sans risque sera le jeu d’autorisations par défaut fourni avec le système d’exploitation.

À quoi ça ressemble ? Examinez de nouveau le manifeste dans Code Listing 1. Notez l’ID donné à PermissionSet défini dans la section TrustInfo, « SeeDefinition ».

Voici à quoi ressemble le jeu d’autorisations sans risque pour la préversion PDC 2003 : Non restreint FileDialogPermission vous permet de lire ou d’écrire des fichiers de son choix via les classes OpenFileDialog et SaveFileDialog standard, mais vous n’êtes pas autorisé à apprendre quoi que ce soit sur la structure du système de fichiers de l’utilisateur, y compris le nom du fichier choisi par l’utilisateur. IsolatedStoragePermission permet à un assembly de lire et d’écrire jusqu’à 5 mégaoctets d’état spécifique à l’utilisateur sur le disque dur de l’utilisateur sans avoir à lui demander d’entrer une boîte de dialogue de fichier. SecurityPermission permet à votre code de s’exécuter en premier lieu. UiPermission vous permet de dessiner à l’écran, mais uniquement dans vos propres fenêtres, et vous accorde un accès limité au Presse-papiers (vous ne pouvez pas lire son contenu par programmation, mais l’utilisateur peut coller à partir du Presse-papiers dans vos contrôles). PrintingPermission vous permet d’imprimer, mais uniquement si vous le faites via la boîte de dialogue d’impression. Votre code ne peut pas démarrer silencieusement les travaux d’impression sans que l’utilisateur sache que vous le faites. L’autorisation spécifique à « Avalon » permet à votre code de créer des fenêtres plein écran tant qu’elles ont une bordure contrôlée par le système d’exploitation (vous ne pouvez donc pas usurper l’écran de connexion, par exemple).

Gardez à l’esprit que cette définition changera presque certainement au fil du temps; il peut même changer avant l’expédition du Longhorn beta. Alors prenez ma description ici avec un grain de sel. Nous espérons que cet article vous aidera à commencer à examiner certaines des fonctionnalités de privilèges minimum dans le .NET Framework, telles que le stockage isolé et les dialogues communs, car la définition finale du jeu d’autorisations sans risque vous obligera très probablement à utiliser ces fonctionnalités pour éviter un dialogue d’approbation.

La définition d’un jeu d’autorisations sans risque n’est pas une tâche triviale. L’équipe de Longhorn sait que si sa définition est trop restrictive, il n’y aura pas assez d’applications qui pourront l’utiliser. Mais si c’est trop permissif, les programmes malveillants vont certainement l’utiliser à mauvais escient. On espère que l’équipe pourra trouver le bon endroit. La figure 1 est un diagramme qui montre la plage de privilèges pour les applications Longhorn, d’une application d’administration bénie jusqu’aux applications conçues pour s’exécuter avec le jeu d’autorisations SEE.

Figure 1. Types d’applications

Outils

La création d’applications avec des privilèges minimum n’a jamais été triviale. Vous devez disposer d’instructions et d’outils pour vous aider. Nous avons vu quelques exemples de ces outils au PDC 2003, dont le premier est Visual Studio® 2005 (nommé « Whidbey » dans la période PDC 2003).

Ce nouvel environnement de développement fournit un certain nombre de fonctionnalités qui facilitent le ciblage d’un environnement à privilèges minimum. Par exemple, vous pouvez choisir un jeu d’autorisations que vous souhaitez appliquer lorsque vous déboguez votre application. L’ensemble d’autorisations SEE est un excellent point de départ pour les applications Longhorn. Pour les applications existantes, votre meilleur pari est de cibler le jeu d’autorisations Internet, qui est assez proche de la façon dont see est défini aujourd’hui.

Une fois que vous avez commencé à déboguer avec des autorisations réduites, vous êtes certain de rencontrer des securityExceptions inattendues. La figure 2 montre un exemple classique où le développeur utilise une boîte de dialogue de fichier pour inviter l’utilisateur à entrer un nom de fichier, puis tente de lire le nom de fichier qui a été donné. Si vous disposez d’une autorisation FileDialogPermission (comme dans le jeu d’autorisations SEE), cela vous permet d’inviter l’utilisateur à entrer un fichier, mais vous n’êtes pas autorisé à voir le nom de fichier choisi par l’utilisateur. Au lieu de cela, vous devez appeler une méthode (OpenFile) pour ouvrir un flux que vous pouvez ensuite utiliser pour lire à partir du fichier. Visual Studio 2005 fournit des conseils pour aider le développeur à trouver la bonne façon d’utiliser la classe OpenFileDialog pour éviter l’exception de sécurité.

Figure 2 : Meilleure prise en charge des outils

Un autre outil utile qui a été annoncé au PDC 2003 est appelé PermCalc. Il s’agit d’un outil en ligne de commande qui évalue un assembly et détermine par heuristique les autorisations dont il a besoin pour s’exécuter. Cette fonctionnalité est également prévue pour inclusion dans Visual Studio 2005. Il s’agit d’un excellent moyen de cibler les environnements avec privilèges minimum. Un outil similaire qui existe aujourd’hui est appelé Le vérificateur d’applications Windows, qui fait partie du Kit de ressources de compatibilité des applications Windows. Cet outil peut vous aider à détecter quand votre application enfreint des règles telles que l’écriture dans des parties protégées du système de fichiers ou du registre.

Résumé

Longhorn promet d’être une excellente plateforme pour les applications avec privilèges minimum. Commencez dès aujourd’hui en écrivant du code managé, tout d’abord. Lors de la création d’applications de bureau, rendez-les conformes À LUA (et utilisez le vérificateur d’applications Windows pour vous aider à case activée votre travail). Si vous le pouvez, ciblez l’ensemble d’autorisations Internet pour l’instant, et vous serez probablement directement intégré au SEE lors de l’expédition de Longhorn.

Pour plus d'informations

Lisez le livre de Brent Rector, Introducing « Longhorn » for Developers.

 

À propos de l’auteur

Keith Brown est consultant indépendant spécialisé dans la sécurité des applications. Il est l’auteur du livre Programming Sécurité Windows (Addison-Wesley, 2000) et écrit un nouveau livre sur la sécurité pour les programmeurs .NET. Lisez le nouveau livre en ligne à l’adresse http://www.develop.com/kbrown.