ID do artigo: 311301 - Última revisão: quinta-feira, 19 de abril de 2007 - Revisão: 5.3

Como o Internet Explorer determina as permissões para módulos (assemblies) do .NET Framework

Dica do SistemaEste artigo aplica-se a um sistema operativo diferente do que está a utilizar. Foi desactivado o conteúdo do artigo, que pode não ser relevante para si.
Expandir tudo | Recolher tudo

Sumário

Aplicativos baseados na Web podem usar o Microsoft Internet Explorer 5.5 e posterior para baixar e executar módulos (assemblies) Microsoft .NET Framework. Este artigo descreve como o Internet Explorer determina as permissões que são concedidas para módulos (assemblies).

Mais Informações

Assemblies do .NET framework que são implantados de uma intranet geralmente recebem o padrão definir permissões de intranet. Este conjunto permite que o código executar somente um conjunto muito limitado de funções. Essas funções incluem o seguinte:
  • Caixa de diálogo de arquivo (somente leitura)
  • Armazenamento isolado
  • Permissão de segurança para executar
  • Permissão de interface do usuário para criar janelas superior-níveis de segurança e usar a área de transferência
O controle gerenciado pode não ser executado no Internet Explorer, a menos que controles ActiveX e scripts estão ativados.

.NET framework Service Pack 1 (ou V1 para essas versões localizadas receber essa alteração) irá definir uma nova diretiva de segurança padrão, no qual gerenciado código não pode ser download a partir da Internet zona em questão.

Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
317399  (http://support.microsoft.com/kb/317399/ ) .NET Framework no padrão alterar diretiva de segurança em nível de máquina
O CLR (Common Language Runtime) foi projetado para dar suporte a uma variedade de diferentes aplicativos .NET Framework. Atualmente, cada tipo de aplicativo requer um trecho de código para iniciar. Esse código é conhecido como um host CLR. A responsabilidade de um host é carregar a versão correta do CLR em um processo, definir os domínios de aplicativo dentro do processo e executar código do usuário dentro desses domínios.

Para fornecer um ambiente isolado para cada tipo de aplicativo, o CLR oferece suporte a vários hosts de runtime diferentes, bem como Internet Explorer. Todos os hosts CLR devem começar com um fragmento de código não gerenciado. Para essa finalidade, o .NET Framework fornece um conjunto de interfaces de programação de aplicativo não gerenciado (APIs). Os hosts do aplicativo podem usar essas APIs não gerenciadas para obter o CLR em execução.

O .NET Framework inclui dois componentes que lidam com os componentes do .NET Framework no Internet Explorer. O primeiro componente, Mscorie.dll, contém um filtro de tipo MIME (Multipurpose Internet Mail Extensions). Este filtro conecta no Internet Explorer e monitora todos os fluxos de dados entrada com o MIME tipo application/octet-stream. Uma função principal dessa correção de inicialização é examinar o fluxo de entrada para ver ou não o fluxo é um código gerenciado. Se o filtro determina que os dados de entrada não são um código gerenciado, o filtro permitirá que para manipular os dados da forma que ele foi anteriormente.

Se o filtro de tipo MIME determina que o fluxo é um módulo do .NET Framework, o filtro carrega o segundo componente. O segundo componente é um assembly gerenciado chamado IEHost. O IEHost chamará a API CorBindToRuntimeByCfg para carregar o CLR em um processo. O IEHost também chama IEManager, um Gerenciador de segurança que cria um domínio de aplicativo dentro do processo. Depois que o host cria e configura o domínio do aplicativo, o host chama em seu objeto de fábrica para criar uma instância do objeto de Framework .NET solicitado e para carregar e executar código de usuário nesse domínio de aplicativo.

Host do Internet Explorer define um aplicativo por site por padrão. O diretório raiz do site é considerado o diretório raiz do aplicativo. O host tem um alto grau de controle sobre as permissões que recebe o código quando ele é executado em um domínio de aplicativo especificado. Todo o código que é executado no Common Language Runtime deve ser parte de um assembly. Todos os aplicativos que tem como alvo o CLR devem interagir com o sistema de segurança do tempo de execução. Quando um aplicativo é executado, o runtime automaticamente avalia o aplicativo. O tempo de execução também oferece o aplicativo um conjunto de permissões. Essas permissões sejam baseiam na evidência que o aplicativo fornece e na diretiva de segurança. Formas comuns de evidências para IEHost incluem StrongName, URL, sites, zona e Publisher.

O CLR permite o código para executar essas operações que o código tem permissão para executar. O .NET Framework contém um objeto de permissão para cada recurso está disponível no computador do usuário. Esses recursos incluem E/s de arquivos, acesso Web, execução de código não gerenciado e muito mais. O tempo de execução usa esses objetos de permissão para impor restrições no código gerenciado.

Para conceder permissões para o código do .NET Framework, os administradores ou usuários avançados grupo as permissões em um conjunto de permissões. A permissão definida e é aplicada a um grupo de códigos. Um assembly específico (a unidade básica de código para conceder permissões de segurança) é um membro de um grupo de código se ele satisfaz a condição de associação do grupo de código.

Para exibir as permissões padrão que são fornecidas para assemblies .NET, use a ferramenta de configuração do .NET Framework (Mscorcfg.msc). Você também pode usar essa ferramenta para exibir e configurar a diretiva de segurança. Os administradores podem definir conjuntos de permissão personalizada-nomeadas, desde que seus nomes são diferentes dos conjuntos de permissão nomeado interna de.

Referências

Adendo do Microsoft .NET Framework 1.0

http://msdn2.microsoft.com/en-us/library/ms973854.aspx (http://msdn2.microsoft.com/en-us/library/ms973854.aspx)

segurança do Internet Explorer e execução gerenciada

http://msdn2.microsoft.com/en-us/library/101853ac(vs.71).aspx (http://msdn2.microsoft.com/en-us/library/101853ac(vs.71).aspx)

hosts do domínio de aplicativo

http://msdn2.microsoft.com/en-us/library/6700e49f(vs.71).aspx (http://msdn2.microsoft.com/en-us/library/6700e49f(vs.71).aspx)

padrão de diretiva de segurança

http://msdn2.microsoft.com/en-us/library/03kwzyfc(vs.71).aspx (http://msdn2.microsoft.com/en-us/library/03kwzyfc(vs.71).aspx)

grupos de códigos

http://msdn2.microsoft.com/en-us/library/ka9xc0ek(vs.71).aspx (http://msdn2.microsoft.com/en-us/library/ka9xc0ek(vs.71).aspx)

evidência

http://msdn2.microsoft.com/en-us/library/7y5x1hcd(vs.71).aspx (http://msdn2.microsoft.com/en-us/library/7y5x1hcd(vs.71).aspx)

Criando suas próprias permissões de acesso código

http://msdn2.microsoft.com/en-us/library/yctbsyf4(vs.71).aspx (http://msdn2.microsoft.com/en-us/library/yctbsyf4(vs.71).aspx)

Microsoft.NET: implementar um host personalizado do Common Language Runtime para seu aplicativo gerenciado

http://msdn.microsoft.com/library/default.asp?url=/msdnmag/issues/01/03/clr/TOC.asp (http://msdn.microsoft.com/library/default.asp?url=/msdnmag/issues/01/03/clr/TOC.asp)

hospedar controles de cliente seguros, leves no Microsoft Internet Explorer

http://msdn.microsoft.com/msdnmag/issues/02/01/UserCtrl/default.aspx (http://msdn.microsoft.com/msdnmag/issues/02/01/UserCtrl/default.aspx)


A informação contida neste artigo aplica-se a:
  • Microsoft .NET Framework Software Development Kit 1.0 Service Pack 2
  • Microsoft Internet Explorer (Programming) 6.0
  • Microsoft Internet Explorer 5.5
Palavras-chave: 
kbmt kbinfo kbsecurity KB311301 KbMtpt
Tradução automáticaTradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 311301  (http://support.microsoft.com/kb/311301/en-us/ )
Retired KB ArticleAviso de Isenção de Responsabilidade sobre Conteúdo do KB Aposentado
Este artigo trata de produtos para os quais a Microsoft não mais oferece suporte. Por esta razão, este artigo é oferecido "como está" e não será mais atualizado.