Segurança em Longhorn: foco no privilégio mínimo

 

Keith Brown
DevelopMentor

Abril de 2004

Aplica-se a:
   Build de versão prévia da PDC (Professional Developers Conference) "Longhorn" da 2003 Professional Developers Conference

Resumo: Longhorn promete ser uma ótima plataforma para aplicativos com privilégios mínimos. Comece hoje escrevendo código gerenciado, em primeiro lugar. Ao criar aplicativos da área de trabalho, torne-os compatíveis com LUA (e use o Verificador de Aplicativos do Windows para ajudar a marcar seu trabalho). (11 páginas impressas)

Sumário

O problema
Manifestos de aplicativo e implantação
LUA: conta de usuário com privilégios mínimos
O grupo de usuários avançados (preterido)
AIM: Gerenciamento de Impacto do Aplicativo
PA: Administrador protegido
Aplicativos gerenciados no Longhorn
O conjunto de permissões "sem risco"
Ferramentas
Resumo

Tenho sido um defensor de concorrer com privilégios mínimos. Muitos que me conhecem ouviram meu discurso de que os desenvolvedores devem parar de executar com privilégios administrativos enquanto desenvolvem código, mesmo que apenas para ajudar a incentivar mais aplicativos a serem escritos para serem executados em ambientes com privilégios mínimos. Então, fiquei muito feliz em ouvir na Conferência de Desenvolvedores Profissionais da Microsoft (PDC) de 2003 que uma das metas main da próxima versão do sistema operacional Windows®, chamada de código "Longhorn", é facilitar a execução dos usuários com privilégios mínimos.

O problema

Quando você compra uma cópia do Microsoft Windows XP® Professional em sua loja de software local e a instala em um computador, o assistente de instalação cria contas para você e qualquer outra pessoa que usará o computador. Depois que o Windows XP é inicializado, ele exibe uma tela de boas-vindas que mostra o nome de cada usuário e permite que ele faça logon. Cada um desses usuários é, por padrão, um administrador do computador. Por quê? Como a experiência do usuário seria ruim se não fosse assim.

Os usuários esperam poder instalar o software em seus computadores, mas você não pode instalar 90% do software atual, a menos que você seja um administrador. Os usuários esperam que o software seja executado sem falhas, mas 70% do software não será executado corretamente, a menos que o usuário seja um administrador e esse seja um número otimista. Infelizmente, um grande número desses aplicativos falha em um ambiente não administrativo simplesmente porque eles fazem escolhas ruins sobre onde salvar o estado do aplicativo. O diretório Arquivos de Programas não se destina a ser um local para armazenar o estado. É um local para armazenar programas , arquivos executáveis. O local para armazenar o estado do aplicativo é chamado de perfil do usuário e, para armazenar o estado do usuário compartilhado, o perfil "Todos os Usuários" é suficiente. As diretrizes do Programa de Logotipo do Windows explicam isso, mas a grande maioria dos softwares do Windows atualmente foi desenvolvida sem considerar as diretrizes do Logotipo do Windows.

Mas por que, você pode perguntar, os usuários devem querer executar como não administradores, especialmente usuários domésticos? Bem, se fosse realmente fácil de fazer, o usuário doméstico colheria um monte de benefícios. O malware (um vírus, worm ou outro código mal-intencionado) adora ter privilégios administrativos. Navegar na Web ou ler emails como administrador é simplesmente perigoso nos dias de hoje. E seus filhos? Não seria bom permitir que eles instalassem e jogassem jogos em seu computador doméstico sabendo que eles não quebrarão algo acidentalmente, instalarão spyware ou removerão as limitações de classificação de conteúdo que você impôs? Pense dessa forma: a execução como administrador desativa efetivamente a maioria das proteções de segurança fornecidas pelo Windows. Usuários domésticos e corporativos não deveriam estar desativando essas proteções, especialmente quando conectados à Internet, que se tornou um bairro bastante perigoso.

Fazer com que os usuários e os programas executados vivam alegremente em um ambiente de privilégios mínimos aumentará significativamente a segurança da plataforma Windows.

Manifestos de aplicativo e implantação

Um recurso importante que o Longhorn apresenta é a noção de manifestos de aplicativo e implantação. O primeiro permite que os desenvolvedores de aplicativos indiquem as permissões que seu aplicativo requer para funcionar corretamente e o último permite que os administradores especifiquem a confiança que colocam no aplicativo. Há muito mais do que isso nesses manifestos, mas quero salientar que eles estão disponíveis para uso por aplicativos gerenciados e não gerenciados, e um grande motivo para sua existência é ajudar os usuários a executar aplicativos com o menor privilégio possível.

Para saber mais sobre esses manifestos, dê uma olhada no Capítulo 1 do livro do Brent Rector Apresentando "Longhorn" para Desenvolvedores.

LUA: conta de usuário do Least-Privilege

LUA, ou Conta de Usuário com Privilégios Mínimos, é um acrônimo que tenho certeza de que você verá repetidas vezes em apresentações da Microsoft a partir de agora. Os apresentadores do PDC 2003 frequentemente pronunciam o acrônimo como "looah". Não é nada chique, nem mesmo nada realmente novo. LUA refere-se à prática de usar contas de usuário sem privilégios, tanto para usuários interativos quanto para serviços.

A equipe do Longhorn quer simplificar a segurança. Eles acreditam que deve haver dois níveis de acesso ao sistema: privilégios mínimos e administrativos. Eles até preteriram o grupo Power Users (conhecido em alguns círculos como "admin-lite") em Longhorn.

Com o grupo Usuários Avançados perdido, os desenvolvedores de aplicativos realmente precisam fazer uma escolha. Eles precisam decidir quais dos dois níveis de privilégio (LUA ou administrativo) seu aplicativo precisa para Longhorn. Se o aplicativo não precisar de privilégios administrativos, ele deverá ser cuidadosamente gravado para funcionar em uma conta de privilégios mínimos. Isso significa testar (e, espera-se, até mesmo escrever o código) usando contas de usuário normais. Por exemplo, um aplicativo LUA deve gravar arquivos de dados em um local seguro, como o perfil do usuário, em vez da árvore de diretório Arquivos de Programas. Mas o que acontece com aplicativos que não são reescritos para Longhorn? E se esses aplicativos não forem executados bem em contas com privilégios mínimos, mesmo no Windows XP? Um recurso do Longhorn chamado AIM (Gerenciamento de Impacto do Aplicativo) pode ajudar esses aplicativos a serem executados em LUA de qualquer maneira, como você verá em breve.

O grupo de usuários avançados (preterido)

Se você pensar em uma conta administrativa com acesso "alto" e uma conta de usuário normal com acesso "baixo", uma conta do Power User poderá ter acesso "médio". O grupo Usuários Avançados tem permissão para ler e gravar partes do sistema de arquivos e do registro que normalmente estão fora dos limites para contas com privilégios mínimos (ou seja, contas de usuário normais que não possuem associação em grupos privilegiados, como Administradores ou Usuários Avançados). Muitas pessoas que tentaram executar como usuários normais descobriram que tanto software falhou que decidiram adicionar suas contas ao grupo Usuários Avançados, o que corrigiu quase todos os problemas que eles estavam tendo. Mas eles não estavam mais correndo com privilégios mínimos. Por exemplo, no Windows XP, qualquer malware executado com esse nível "médio" de privilégio poderá comprometer outros aplicativos armazenados no diretório Arquivos de Programas, substituir componentes COM confiáveis por Trojans e assim por diante. Na próxima vez que o usuário for executado sob sua conta administrativa em um computador tão comprometido, você poderá ter certeza de que o malware também será executado por meio de um Trojan instalado anteriormente. Portanto, você não está recebendo nenhuma proteção real em execução como um Usuário Avançado.

AIM: Gerenciamento de Impacto do Aplicativo

A equipe de Longhorn acredita que correr com privilégios mínimos é importante. Eles querem que essa tela de boas-vindas contenha uma lista de contas de usuário que consistem principalmente em contas com privilégios mínimos. Mas eles também têm os pés aterrados na realidade. Assim como muitos dos principais softwares de hoje ignoram completamente o Programa de Logotipo do Windows, muitos softwares importantes no período longhorn também podem ignorar a iniciativa LUA. Os desenvolvedores de aplicativos nãoformados continuarão a escrever software que lê e grava arquivos de dados da árvore de diretório Arquivos de Programas. Eles também continuarão a gravar dados do Registro em HKEY_LOCAL_MACHINE em vez de HKEY_CURRENT_USER. O primeiro está fora dos limites para gravação por usuários normais, portanto, este último é preferível para armazenar as configurações do aplicativo, se o registro precisar ser usado.

Quando o Windows XP pode detectar que um aplicativo precisa de mais privilégios (isso é raro, mas acontece ocasionalmente com programas de instalação), ele informará ao usuário sem privilégios que o aplicativo requer privilégios administrativos para ser executado, convenientemente aparecendo uma caixa de diálogo para coletar o nome de usuário e a senha de uma conta de administrador. Em seguida, o programa é executado na conta especificada. Mas isso nem sempre funciona porque muitos aplicativos não são gravados para serem instalados em uma conta e usados em outra.

Longhorn tem uma abordagem completamente diferente. Em vez de incentivar o usuário a elevar privilégios para que o aplicativo possa funcionar corretamente, o Longhorn prefere executar o aplicativo em LUA. Mas o que acontece quando o aplicativo tenta gravar no HKEY_LOCAL_MACHINE ou na árvore de diretório arquivos de programas? O Longhorn fornece ao aplicativo sua própria exibição virtualizada do recurso que ele está tentando alterar, usando uma estratégia de cópia em gravação. Quando o aplicativo tentar gravar em um arquivo no diretório Arquivos de Programas, o Longhorn fornecerá ao aplicativo sua própria cópia privada do arquivo e ele poderá fazer parte dele. Dessa forma, qualquer malware que fique solto em um cenário AIM pode tentar substituir um executável comumente usado na árvore de diretório arquivos de programas, talvez WINWORD.EXE. Mas o que ele vai acabar substituindo é uma cópia privada que só o malware pode ver. A versão do WINWORD.EXE que o usuário vê ainda será a versão original e não pertencente.

Não confie em AIM para salvá-lo. Escreva seu aplicativo para ser executado em LUA desde o primeiro dia.

PA: Administrador protegido

Mesmo que cada aplicativo seja corrigido no período longhorn para ser executado em LUA, ainda haverá aplicativos que realmente exigem privilégios administrativos. Eles incluem utilitários como software de backup, desfragmentação de disco rígido e software de repartição, software de gerenciamento corporativo e a lista continua. Portanto, em algum momento, o usuário precisará usar uma conta administrativa para realizar determinados trabalhos. E vamos encarar, muitas pessoas ignorarão os conselhos para criar contas LUA e simplesmente serão executadas como administradores o tempo todo.

A equipe do Longhorn criou um esquema simples para ajudar a protegê-lo quando você estiver executando em uma conta administrativa. É um recurso chamado Administrador Protegido e, quando ele é ativado, você sempre pode executar em uma conta administrativa e se sentir razoavelmente seguro, pois a grande maioria dos aplicativos executados será executada com um token restrito especial, um token semelhante ao que você teria em um cenário LUA. Somente um aplicativo que você tenha "abençoado", ou que sua empresa tenha implantado e designado como confiável, será executado com seu token administrativo completo. Uma maneira de designar um aplicativo como confiável é assinando seu manifesto de implantação. Por que isso é útil? Deixe-me dar um exemplo.

Um usuário que normalmente é executado como administrador abre seu cliente de email longhorn e começa a navegar por email. Ela se depara com um pedaço de correio que veio de alguém que ela conhece, e abre um anexo. Mal sabe ela que sua amiga foi infectada recentemente por um verme de e-mail, e esta mensagem contém malware. Quando o malware é executado, ele descobre que ele tem muito pouco privilégio no sistema. Ele não pode modificar nada na árvore de diretório arquivos de programas. Ele não pode alterar os registros de objeto COM em HKEY_LOCAL_MACHINE. Isso não quer dizer que não possa fazer nada de ruim, mas a situação é muito melhor do que teria sido se o malware se encontrasse em execução com privilégios administrativos.

Mas espere, eu não disse que o usuário estava executando como administrador quando ela executou o aplicativo de email? Sim, isso foi de fato o caso. Mas o aplicativo de email não foi designado como um aplicativo de administração "abençoado"; na verdade, foi escrito como um aplicativo LUA. Assim, ele recebeu um token restrito, assim como o malware como resultado. Esse é o ponto de privilégio mínimo. Se você perder o controle do sistema (talvez porque você executou acidentalmente algum software maléfico ou talvez porque você acabou de clicar no item de menu errado), o dano será restrito ou talvez completamente evitado.

Alguns administradores conscientes da segurança já implementam essa política hoje. Eu sou um deles. Tenho duas contas, uma normal e uma administrativa. Faço logon como um usuário normal e, ocasionalmente, altero para minha conta administrativa quando preciso administrar meu sistema de alguma forma, por exemplo, para adicionar um diretório virtual no meu computador, criar um banco de dados no Microsoft SQL™ Server e assim por diante. (Caso você esteja se perguntando, eu acabarei gastando cerca de 95% do meu tempo em execução como um usuário normal, mesmo ao desenvolver software.) A equipe do Longhorn formalizou essa abordagem, uma ideia geralmente chamada de "privilégio certo no momento certo" no recurso de PA (Administrador Protegido) para abreviar. Isso significa que posso apenas executar como administrador o tempo todo, mas ainda estar em execução com privilégios mínimos. Chega de alternar para frente e para trás, fazendo malabarismos com dois perfis de usuário e assim por diante.

Se isso parecer uma ideia interessante e você quiser ajudar a tornar possível que as pessoas realmente usem esse recurso, você precisará levar a sério a escrita de aplicativos que são executados com privilégios mínimos. Como se esse recurso estiver habilitado, um aplicativo que requer mais privilégios do que realmente precisa será interrompido desnecessariamente, mesmo que um administrador o execute, a menos que tenha sido designado como um aplicativo de administração confiável. É claro que o AIM pode vir para o seu resgate, mas você não deve confiar nele, porque a Microsoft está estimando que 20% dos aplicativos provavelmente não serão capazes de se tornar compatíveis com LUA por meio do AIM. Se você cair nesses 20%, o aplicativo não será executado. Se isso acontecer o suficiente, ninguém usará o recurso Administração Protegido, e isso seria realmente uma coisa muito triste.

Outros benefícios surgirão à medida que mais aplicativos forem escritos que são executados com privilégios mínimos. Por exemplo, as corporações finalmente poderão bloquear suas estações de trabalho, permitindo que os funcionários executem em contas com privilégios mínimos. Isso simplificará significativamente a administração e reduzirá os custos. Agora, mais do que nunca, é importante escrever aplicativos que são executados com privilégios mínimos. Você pode fazer a diferença nesta plataforma.

Aplicativos gerenciados no Longhorn

Uma das mensagens do PDC 2003 foi que os aplicativos gerenciados são o futuro. Ao escrever código gerenciado, você pode aproveitar a última revolução na segurança na plataforma Windows: segurança por meio da identidade de código. O sistema de segurança baseado em evidências fornecido pelo CLR (Common Language Runtime) e geralmente chamado de CAS, ou segurança de "acesso ao código", permite que o CLR coloque restrições extras no código com base em onde ele veio, quem o assinou e assim por diante. Essa dimensão adicional de segurança abre novos caminhos para a distribuição de software. Ao executar o código em uma área restrita segura, os clientes agora podem executar com confiança o código baixado de um servidor central, o que torna os recursos como "sem toque" e a implantação de "clique uma vez" viáveis, reduzindo ainda mais os custos de administração. E quem não prefere um aplicativo real do Windows em execução em seu computador a um aplicativo baseado em navegador, se os riscos de implantação e segurança fossem semelhantes?

No Longhorn, cada aplicativo gerenciado pode indicar as permissões específicas necessárias para funcionar por meio do manifesto do aplicativo. A listagem de código 1 mostra um manifesto de exemplo gerado quando criei um projeto "Aplicativo Longhorn" gerado pelo assistente padrão. Observe a seção TrustInfo e o conjunto de permissões expressas lá. Essas são as permissões que o aplicativo precisa executar.

Listagem de código 1. Um manifesto do aplicativo

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

Um aplicativo gerenciado compatível com LUA sempre incluirá uma seção como esta, e o gerenciador de confiança no Longhorn usará essas informações para determinar se o aplicativo deve ser instalado no computador. Se o aplicativo for codificado cuidadosamente, ele poderá ser executado com privilégios tão baixos que o gerenciador de confiança pode atribuir a ele uma pontuação de "sem risco", e o aplicativo pode ser instalado imediatamente e executado sem intervenção do usuário. No entanto, se o aplicativo pontuar uma classificação de risco mais perigosa com base nas permissões solicitadas, o usuário será solicitado com uma caixa de diálogo que descreve os perigos potenciais que o aplicativo representa. Em seguida, o usuário pode escolher se deseja permitir que o aplicativo seja instalado e executado.

Declarar suas intenções antecipadamente no manifesto é uma boa ideia, porque se você não fizer isso, o gerente de confiança só poderá assumir o pior sobre seu aplicativo, e a classificação de risco expressa ao usuário parecerá ainda mais sinistra. Portanto, é uma boa ideia expressar as permissões necessárias em seu manifesto. Não ignore esta etapa.

Em um estudo mencionado no PDC 2003, a Microsoft descobriu que 40% dos usuários sempre clicam em "Não" quando apresentados com caixas de diálogo de segurança, como avisos de download de controle ActiveX. É claro que, se você quiser distribuir seu software para os usuários pela Internet, estará esperando uma classificação de risco "sem risco" do gerenciador de confiança no Longhorn, para que o usuário não seja solicitado antes de instalar e executar seu aplicativo. Portanto, você pode estar se perguntando se há um conjunto documentado de permissões que sempre será pontuado como "sem risco". Acontece que há uma definição desse tipo e é conhecida como o conjunto de permissões SEE.

O conjunto de permissões "sem risco"

Você pode ter ouvido isso em PDC 2003 como SEE (Ambiente de Execução Segura), mas a maioria das pessoas acha esse termo bastante confuso, portanto, vou simplesmente chamar isso de conjunto de permissões sem risco. Longhorn será enviado com um conjunto de permissões especial que sempre pontuará "sem risco" com o gerenciador de confiança padrão em Longhorn. Se você escrever um aplicativo cujos requisitos de permissão se enquadram inteiramente no conjunto de permissões sem risco, ele poderá ser instalado e executado sem mostrar nenhum aviso de confiança. O código que recebe permissões somente dentro desse conjunto (pelo menos como é definido pela Microsoft inicialmente) não deve ser capaz de prejudicar seu computador intencionalmente ou acidentalmente.

Portanto, se você quiser que seu aplicativo seja instalado e executado sem que o usuário seja solicitado com uma caixa de diálogo assustadora, você desejará restringir-se às atividades permitidas por esse conjunto de permissões. Você deve saber que a equipe do Longhorn está considerando tornar esse conjunto de permissões configurável pelos administradores, portanto, o que é considerado "sem risco" em um site pode ser diferente em outro. Mas para a grande maioria das instalações de Longhorn, o conjunto de permissões sem risco será o padrão fornecido com o sistema operacional.

Como é que ele se parece? Examine o manifesto na Listagem de Códigos 1. Observe a ID fornecida ao PermissionSet definido na seção TrustInfo, "SeeDefinition".

Aqui está a aparência do conjunto de permissões sem risco para o build de versão prévia do PDC 2003: Unrestricted FileDialogPermission permite que você leia ou escreva arquivos da escolha do usuário por meio das classes Padrão OpenFileDialog e SaveFileDialog , mas você não tem permissão para aprender nada sobre a estrutura do sistema de arquivos do usuário, incluindo o nome do arquivo escolhido pelo usuário. O IsolatedStoragePermission permite que um assembly leia e escreva até 5 megabytes de estado específico do usuário no disco rígido do usuário sem precisar solicitá-la com uma caixa de diálogo de arquivo. O SecurityPermission permite que seu código seja executado em primeiro lugar. A UIPermission permite que você desenhe na tela, mas apenas em suas próprias janelas, e concede acesso limitado à área de transferência (você não pode ler seu conteúdo programaticamente, mas o usuário pode colar da área de transferência em seus controles). PrintingPermission permite que você imprima, mas somente se você fizer isso por meio da caixa de diálogo de impressão. Seu código não pode iniciar trabalhos de impressão silenciosamente sem que o usuário saiba que você está fazendo isso. A permissão específica de "Avalon" permite que seu código crie janelas de tela inteira, desde que elas tenham uma borda controlada pelo sistema operacional (para que você não possa falsificar a tela de logon, por exemplo).

Tenha em mente que essa definição certamente mudará ao longo do tempo; pode até mudar antes que a versão beta de Longhorn seja enviada. Então, pegue minha descrição aqui com um grão de sal. Esperamos que este artigo ajude a motivar você a começar a examinar alguns dos recursos de privilégios mínimos no .NET Framework como armazenamento isolado e caixas de diálogo comuns, pois a definição final do conjunto de permissões sem risco provavelmente exigirá que você use esses recursos para evitar uma caixa de diálogo de confiança.

Definir um conjunto de permissões sem risco não é uma tarefa trivial. A equipe do Longhorn sabe que, se sua definição for muito restritiva, não haverá aplicativos suficientes para usá-la. Mas se for muito permissivo, o malware definitivamente o usará indevidamente. Espera-se que a equipe possa encontrar o ponto doce. A Figura 1 é um diagrama que mostra o intervalo de privilégios para aplicativos Longhorn, desde um aplicativo de administrador abençoado até aplicativos projetados para serem executados com o conjunto de permissões SEE.

Figura 1. Tipos de aplicativos

Ferramentas

A criação de aplicativos com privilégios mínimos nunca foi trivial. Você precisa ter diretrizes e ferramentas para ajudar. Vimos alguns exemplos dessas ferramentas no PDC 2003, o primeiro deles é o Visual Studio® 2005 (cocódigo "Whidbey" no período PDC 2003).

Esse novo ambiente de desenvolvimento fornece uma série de recursos que ajudam a facilitar a segmentação de um ambiente de privilégios mínimos. Por exemplo, você pode escolher um conjunto de permissões que deseja impor ao depurar seu aplicativo. Um ótimo lugar para começar para aplicativos Longhorn seria o conjunto de permissões SEE. Para aplicativos existentes, sua melhor opção é direcionar o conjunto de permissões da Internet, que está muito próximo de como o SEE é definido hoje.

Depois de iniciar a depuração com permissões reduzidas, você certamente encontrará algumas SecurityExceptions inesperadas. A Figura 2 mostra um exemplo clássico em que o desenvolvedor usa uma caixa de diálogo de arquivo para solicitar um nome de arquivo ao usuário e tenta ler o nome de arquivo que foi dado. Se você receber FileDialogPermission (como está no conjunto de permissões SEE), isso permitirá que você solicite um arquivo ao usuário, mas você não está autorizado especificamente a ver o nome de arquivo escolhido pelo usuário. Em vez disso, você deve chamar um método (OpenFile) para abrir um fluxo que você pode usar para ler do arquivo. O Visual Studio 2005 fornece conselhos para ajudar o desenvolvedor a encontrar a maneira correta de usar a classe OpenFileDialog para evitar a exceção de segurança.

Figura 2. Melhor suporte à ferramenta

Outra ferramenta útil que foi anunciada no PDC 2003 é chamada PermCalc. Essa é uma ferramenta de linha de comando que avalia um assembly e determina por meio de heurística as permissões necessárias para execução. Esse recurso também está planejado para inclusão no Visual Studio 2005. Essa é uma ótima maneira de direcionar ambientes com privilégios mínimos. Uma ferramenta semelhante que existe hoje é chamada de Verificador de Aplicativos do Windows, parte do Kit de Ferramentas de Compatibilidade de Aplicativos do Windows. Essa ferramenta pode ajudá-lo a detectar quando seu aplicativo viola regras como gravar em partes protegidas do sistema de arquivos ou do registro.

Resumo

Longhorn promete ser uma ótima plataforma para aplicativos com privilégios mínimos. Comece hoje escrevendo código gerenciado, em primeiro lugar. Ao criar aplicativos da área de trabalho, torne-os compatíveis com LUA (e use o Verificador de Aplicativos do Windows para ajudar a marcar seu trabalho). Se puder, direcione o conjunto de permissões da Internet por enquanto e provavelmente caberá diretamente no SEE quando Longhorn for enviado.

Para obter mais informações

Leia o livro de Brent Rector, Apresentando "Longhorn" para desenvolvedores.

 

Sobre o autor

Keith Brown é um consultor independente especializado em segurança de aplicativos. Ele criou o livro Programming Segurança do Windows (Addison-Wesley, 2000) e está escrevendo um novo livro de segurança para programadores .NET. Leia o novo livro online em http://www.develop.com/kbrown.