Namespaces

Variants
Actions

Please note that as of October 24, 2014, the Nokia Developer Wiki will no longer be accepting user contributions, including new entries, edits and comments, as we begin transitioning to our new home, in the Windows Phone Development Wiki. We plan to move over the majority of the existing entries over the next few weeks. Thanks for all your past and future contributions.

Data caging (Português)

From Wiki
Jump to: navigation, search
Article Metadata

Artigo
Tradução:
Originado de Data caging
Por lpvalente
Última alteração feita por hamishwillee em 16 Dec 2011


Contents

Definição

O particionamento de dados implica em separar dados de código, de modo que se crie um único atalho (path) confiável em uma determinada plataforma. A idéia principal é que ao "aprisionar" ("cage") os processos que não possuem a capacidade TCB em um diretório isolado, os arquivos de sistema tornam-se invisíveis para eles.

O "aprisionamento de dados" ("data caging") significa que as aplicações podem acessar apenas certas áreas do sistema de arquivos. Na prática, as aplicações podem acessar seus próprios diretórios e os diretórios que são classificados como abertos. Isso significa que uma aplicação não pode acessar a área privada de outra aplicação.

O sistema de arquivos possui a seguinte estrutura:

*/sys/

O diretório /sys é uma área de sistema restrita e inacessível a aplicações que não possuam a capacidade TCB (Essa capacidade é requerida para se alterar o conteúdo do diretório sys, mas se for somente para ler pode ser usada a capacidade AllFiles).

O diretório sys possui um subdiretório chamado /sys/bin, que armazena todos os executáveis (EXEs, DLLs, etc). Por ser um diretório sem ramificações, todos os arquivos (EXE, DLL, e outros) precisam ter nomes diferentes. O sistema operacional irá se recusar a carregar executáveis que estejam em outros diretórios.

*/private/

Aplicações que não possuem a capacidade TCB possuem uma visão restrita do sistema de arquivos, que consiste na sub-árvore de diretórios /private/<SID>/, onde SID corresponde ao identificador de segurança único da aplicação. Aplicações podem usar esse diretório para armazenar seus arquivos de dados. Outros processos precisam ter a capacidade AllFiles para acessar esse diretório.

Esse diretório pode ser usado livremente pela aplicação para ler e escrever. Aplicações responsáveis por fazer backup possuem permissões de leitura e escrita para esse diretório.

*/resource/

Esse diretório é publico, mas somente para leitura para processos que não possuem a capacidade TCB. A motivação para essa abordagem é permitir que arquivos sejam compartilhados entre processos, sem comprometer a integridade desses arquivos. Aplicações que não possuam capacidades podem ler esses arquivos.

A capacidade TCB é necessária para que uma aplicação possa alterar o conteúdo desse diretório. Os instaladores de aplicações podem adicionar ou alterar arquivos. Subdiretórios podem ser usados para garantir que todos os nomes sejam únicos.

Esses diretórios protegidos podem ser armazenados em discos fixos ou removíveis. Todos os outros diretórios não são protegidos, de modo que não é seguro armazenar dados confidenciais nesses locais. Normalmente, são usados para se armazenar ícones ou imagens das aplicações, entre outras coisas.

*/restante dos diretórios/

Acesso a todos os outros diretórios não é restrito, e eles podem ser usados para qualquer coisa, como armazenar fotos, músicas e documentos do usuário.

Usando um diretório de importação

Alguns servidores podem ter suas funcionalidades extendidas através de plugins. Eles conseguem descobrir a existência de plugins ao inspecionar o diretório onde os plugins ficam normalmente armazenados.

Como os arquivos de recursos são de interesse somente de um determinado servidor, é natural colocá-los em seu próprio diretório privado. Entretanto, como o instalador de aplicações consegue decidir se é seguro que um pacote SIS qualquer possa instalar um arquivo, em um diretório privado de outro processo ?

A solução está na forma de um conceito chamado "diretório de importação". O instalador de aplicações somente permite que um pacote instale arquivos em um diretório de outro processo se este diretório tiver o nome "import", e se esse diretório já existir. Em outras palavras, o diretório deve ser da forma /private/<process_sid>/import/.

Como um exemplo, o diretório onde são armazenados os arquivos de registro das aplicações: \private\10003a3f\import\apps.

Usando DLLs polimórficas

Não é possível mais inspecionar o diretório \sys\bin em busca de DLLS. sem ter as capacidades de acesso requeridas. Dessa forma, a pesquisa por DLLS deve ser feita com o uso de TFindLibrary, que é capaz de achar DLLS cujos nomes completos sigam um padrão especificado. Depois que a DLL polimórfica for encontrada, pode-se usar o método Handle() para obter o identificador associado (handle) com objeto existente no kernel. Um identificador de DLL polimórfica permite que uma aplicação carregue e feche uma determinada DLL polimórfica. Com esse identificador, também é possível obter ponteiros para funções exportadas pela DLL. O sistema pode verificar se uma DLL polimórfica é do tipo correto ao inspecionar o tipo de sua [[[UID]|UID (Inglês)]].

Links Internos


[[Category:]]

This page was last modified on 16 December 2011, at 04:40.
205 page views in the last 30 days.

Was this page helpful?

Your feedback about this content is important. Let us know what you think.

 

Thank you!

We appreciate your feedback.

×