SEAndroid & SELinux, Making Devices More Secure: A Technology Primer

0
74

Segurança quando se trata de Android sempre foi um tópico muito debatido na indústria. À medida que os OEMs tentam adaptar o Android a novos dispositivos, a segurança (ou a falta dela) é uma grande preocupação para eles. Isso é especialmente verdadeiro para OEMs que usam Android para desenvolver telefones IP empresariais , dispositivos médicose outros dispositivos que têm uma necessidade maior de segurança do que dispositivos de entretenimento doméstico para o consumidor. O HSC trabalha com muitos desses OEMs e ajuda não apenas a personalizar o Android para seus propósitos, mas também a aplicar e fazer cumprir as políticas de segurança apropriadas para seus setores verticais. No passado recente, o SE Android e o SE Linux desempenharam um papel importante nas implementações de segurança do HSC para OEMs. A seguir, um guia de tecnologia sobre o que são SELinux e SE Android e como eles podem ajudar a fortalecer dispositivos baseados em Android.

O que é SELinux?

SELinux é uma implementação de Controle de Acesso Obrigatório para o sistema operacional Linux. Ele fornece uma estrutura de controle de acesso onde o acesso aos recursos do sistema operacional por usuários / processos é controlado com base em uma política de segurança predefinida. A política de segurança é definida e gerenciada centralmente por um administrador de sistema, imposta no nível do kernel do Linux.

Por que precisamos disso?

O Linux usa um sistema de controle de acesso discricionário (DAC) para controlar o acesso aos recursos do sistema operacional. O DAC controla como um processo interage com outro processo e como um processo interage com os recursos do sistema (arquivos, dispositivos etc.). Em sistemas DAC, um usuário atribui permissões de acesso aos recursos de sua propriedade. Por exemplo, todo arquivo no Linux tem permissões de leitura, gravação e execução – essas permissões podem ser modificadas pelo proprietário do arquivo. Os processos iniciados por um usuário têm todas as permissões desse usuário. Nesse tipo de sistema de controle de acesso, se um processo estiver comprometido, esse processo pode executar todas as tarefas no nível de acesso do usuário. Portanto, um processo “raiz” explorado pode causar danos significativos.

Por outro lado, um sistema de Controle de Acesso Obrigatório (MAC) funciona com o princípio do menor privilégio. De acordo com o princípio dos privilégios mínimos, um processo deve ter acesso apenas aos recursos necessários para suas operações e não deve ter acesso a nenhum outro recurso. Por exemplo, um servidor TCP deve ser capaz de criar soquetes TCP e aceitar a conexão. No entanto, não deve ser permitido criar sockets NETLINK. Com esse tipo de controle de acesso, mesmo quando um processo está comprometido, os danos causados ​​por ele serão restritos porque o MAC permitirá que ele tenha apenas os privilégios necessários para realizar seu trabalho. A Red Hat Magazine descreve algumas das explorações que foram interrompidas pelo Controle de Acesso Obrigatório no SELinux.

Terminologia SELinux
Esta seção descreve alguns dos termos importantes que são usados ​​no SELinux:

Objeto – recursos do sistema, como arquivos, diretórios, soquete, interface de rede, etc., são chamados de objetos.

Assunto – um assunto é uma entidade que faz com que uma ação seja executada no objeto. Um sujeito pode ser uma pessoa, um processo ou um dispositivo.

Servidor de segurança – um servidor de segurança é a entidade no kernel do Linux que toma a decisão se uma ação em um objeto por um sujeito é permitida, por política de segurança.

Access Vector Cache – o access vector cache (AVC) melhora o desempenho do sistema ao armazenar em cache as decisões de segurança tomadas pelo servidor de segurança.

Gerenciador de objetos – o gerenciador de objetos gerencia as ações nos objetos. Sempre que um assunto solicita ações em um objeto, o gerenciador de objetos consulta o servidor de segurança para verificar se essa ação é permitida. As decisões de acesso tomadas pelo servidor de segurança são aplicadas pelo gerenciador de objetos.

Identificador de tipo – o SELinux associa um identificador de tipo a cada sujeito e objeto. O identificador de tipo é usado para impor regras de política. Os identificadores de tipo SELinux são cadeias de comprimento variável que são definidas na política de segurança. Um identificador de tipo associado a um assunto é chamado de domínio e um identificador de tipo associado a um objeto é chamado de tipo de objeto .

Usuário SELinux – os nomes dos usuários do SELinux não são iguais aos nomes dos usuários do Linux. Os nomes de usuário do Linux são associados a uma pessoa que usa o Linux, enquanto os nomes de usuário do SELinux são associados a um grupo ou classe de usuários relacionados às políticas de segurança no nível do SELinux. Cada nome de usuário do Linux possui um nome de usuário SELinux associado. Um único nome de usuário SELinux pode ser atribuído a mais de um nome de usuário Linux – por exemplo, todos os usuários Linux padrão podem ser atribuídos user_u nome de usuário SELinux e administradores podem ser atribuídos admin_u. Esta é uma propriedade muito útil porque, desta forma, o SELinux pode aplicar políticas de segurança muito mais granulares e não ficar restrito às permissões de segurança de nível uid / gid do linux.

Função SELinux – no SELinux, cada usuário é associado a uma ou mais funções SELinux, e a função SELinux é novamente associada a um ou mais domínios. Essa estrutura é usada para impor o acesso à base de funções (RBAC).

Contexto de segurança – o servidor de segurança SELinux usa um contexto de segurança para decidir se um acesso é permitido. O contexto de segurança SELinux é uma string de comprimento variável que consiste em usuário SELinux, função, identificador de tipo e intervalo MCS / MLS1 opcional.

O contexto de segurança também é chamado de “rótulo de segurança” ou “rótulo”. Para a decisão de acesso em relação a um assunto, todos os componentes do contexto de segurança são usados, para a decisão de acesso em relação a uma função apenas de objeto, os campos de tipo e intervalo são usados.

Política de segurança –  uma política SELinux é um conjunto de regras que categoriza os processos em vários domínios e particiona os recursos do sistema em categorias de objetos. A política define se um objeto está acessível a partir de um domínio ou não. Ele também determina se a interação entre dois domínios é permitida ou não. Os tipos permitidos para entrada em um domínio também são definidos na política. Qualquer coisa que não seja explicitamente permitida na política é negada pelo servidor de segurança.

Arquitetura SELinux

SELinux MAC é implementado como um módulo de segurança que usa a estrutura do Linux Security Module (LSM).

Os Módulos de Segurança do Linux fornecem uma estrutura de propósito geral para controle de acesso. O LSM medeia o acesso a objetos do kernel, como i-nodes, arquivos abertos, interfaces de rede, etc.

Sempre que um processo do espaço do usuário tenta acessar um objeto do kernel, o controle passa por um mecanismo de chamada do sistema Linux e, pouco antes de o kernel tentar acessar o objeto interno, um gancho LSM é chamado para descobrir se o acesso ao objeto do kernel deve ser permitido.

LSM Hook Architecture
O LSM fornece uma variedade de ganchos para mediar o acesso aos objetos do kernel. 
A seguir estão alguns dos ganchos LSM para objetos kernel:

Ganchos de  tarefa 
– os ganchos de tarefa cobrem todo o ciclo de vida de uma tarefa e são usados ​​para verificar a elegibilidade de uma tarefa para criar uma tarefa, esperar por uma tarefa, sinalizar uma tarefa ou eliminar uma tarefa.

Ganchos de carregamento de programa 
– os  ganchos de carregamento de programa fornecem verificações de acesso durante um novo carregamento de programa (execve).

Ganchos do  sistema de arquivos – os ganchos do sistema de arquivos fornecem verificações de controle de acesso durante a montagem, desmontagem, criação, exclusão, vinculação, renomeação, desvinculação, fnctl, ioctl do sistema de arquivos, etc.
Ganchos IPC –  os ganchos IPC controlam o acesso à memória compartilhada do Linux, semáforos e filas de mensagens.
Ganchos de  módulo 
 ganchos de módulo fornecem controle de acesso durante o carregamento e descarregamento do módulo do kernel.

Ganchos de  soquete 
 os ganchos de soquete executam verificações de acesso para operações de soquete, como criação de soquete, vinculação, conexão, escuta e envio de msg.

Em resumo, o kernel do Linux tem ganchos LSM em cada ponto onde um acesso a recursos precisa ser mediado. 
A interface LSM é implementada como uma estrutura de métodos de retorno de chamada e um módulo de segurança é responsável por implementar esses retornos de chamada. 
O servidor de segurança SELinux se registra no LSM como um módulo de segurança e implementa os callbacks invocados pelo LSM.
LSM_Hooks_For_Kernal_Objects

LSM Hooks

Um gancho LSM consulta o servidor de segurança para verificar se o acesso a um objeto é permitido. Então, usando o contexto de segurança do assunto, o contexto de segurança do objeto e a classe do objeto, o servidor de segurança consulta a política de segurança e decide se o acesso deve ser permitido ou não. As decisões tomadas pelo servidor de segurança são armazenadas em cache no cache do vetor de acesso para acelerar futuras decisões de acesso para o mesmo objeto.

Por que precisamos do SEAndroid?
Os dispositivos Android estão cada vez mais sendo usados ​​para acessar aplicativos corporativos e serviços bancários. Isso resultou em uma necessidade de segurança aprimorada no sistema operacional Android e, além disso, há uma necessidade de maior isolamento entre aplicativos corporativos e não corporativos, a fim de evitar vazamentos de dados corporativos por aplicativos maliciosos. Também é essencial evitar o aumento de privilégios por aplicativos para manter a integridade de aplicativos e dados. SEAndroid pode ajudar a alcançar todos esses objetivos.

O mecanismo de segurança que o Android já possui

O Android já possui sandbox de aplicativos em nível de kernel. Este sandboxing funciona na proteção baseada no usuário do Linux. O Android atribui um ID de usuário exclusivo para cada aplicativo e os aplicativos são executados em processos separados com o ID de usuário atribuído. Isso isola os processos de aplicativo uns dos outros e evita que um aplicativo acesse dados privados de outro.

O Android tem seu próprio modelo de permissão baseado no usuário. Nesse modelo, um aplicativo só pode acessar os serviços para os quais um usuário concedeu permissões explicitamente; usando DAC para restringir o acesso aos recursos do sistema. Apenas aplicativos privilegiados têm permissão para acessar recursos do sistema diretamente e outros aplicativos podem acessar esses recursos por meio do aplicativo privilegiado.

O Android mantém o kernel, a estrutura do Android e os aplicativos do sistema em uma partição separada do sistema. Esta partição é montada como somente leitura para evitar que qualquer aplicativo malicioso adultere binários que são importantes para a operação do sistema.

Por que essa segurança existente não é adequada

O upload de aplicativos maliciosos para o Google Play é fácil, pois não há inspeção / teste de código feito pelo Google antes de disponibilizar um aplicativo para os usuários. Ataques de escalonamento de privilégios têm sido usados ​​por aplicativos maliciosos para acionar downloads não autorizados, enviando SMS para números premium. Os exploits “GingerBreak” foram usados ​​no Android Gingerbread para obter acesso root no dispositivo. Muito fácil.

O Android tem a maioria dos problemas típicos de sistemas baseados em DAC, onde uma permissão de acesso não intencional concedida por um usuário ou aplicativo pode ser fortemente explorada por aplicativos maliciosos.

Algumas das explorações conhecidas do Android foram corrigidas, outras não. Encontre uma lista completa aqui .

Como o SEAndroid ajuda?
O SEAndroid, que se baseia no SELinux, ajuda a confinar daemons do sistema com privilégios no caso de serem comprometidos e limita os danos causados ​​por eles. Também ajuda na criação de um Application Sandbox mais forte, além dos mecanismos existentes baseados em DAC. SEAndroid fortalece o isolamento de dados entre aplicativos, controlando IPC entre aplicativos e entre aplicativos e serviços do sistema.

Como o SEAndroid é diferente do SELinux?
O SEAndroid traz todos os recursos do SELinux para o Android e torna a infraestrutura de segurança muito mais robusta. O kernel Android é ligeiramente diferente de um kernel Linux padrão (componentes adicionais específicos do Android foram adicionados), mas o espaço do usuário Android é completamente diferente das distribuições Linux padrão. Portanto, apenas habilitar o SELinux no Android não é suficiente para protegê-lo completamente de aplicativos maliciosos; você deve empregar SEAndroid.
As subseções a seguir descrevem os recursos implementados pelo SEAndroid para cuidar dos componentes e problemas específicos do Android.

Espaço do Kernel
O kernel Android tem alguns componentes que não estão presentes no kernel Linux padrão. Esses componentes incluem Binder, ashmem, logger e out of memory killer. O Binder é a base da estrutura de comunicação entre os componentes no Android e é muito usado por aplicativos e processos do sistema Android. Como o Binder é um novo componente, novos ganchos LSM foram definidos e adicionados ao driver do Binder. Portanto, SEAndroid fornece implementações desses ganchos LSM para Binder. Por meio desses ganchos LSM, o SEAndroid controla quais aplicativos podem se comunicar uns com os outros e realiza operações de controle de auditoria no Binder.

Espaço do usuário
SELinux instrumentou o código do Android Framework; inserir vários ganchos para a aplicação das políticas de segurança SEAndroid. Alguns dos componentes do espaço do usuário do Android que foram modificados para SEAndroid incluem init, Zygote, Bionic, installd e Dalvik. Todos esses componentes utilizam serviços de “ libselinux ” que permitem que o processo de espaço do usuário interaja com o MAC do kernel e reforce as políticas de segurança.

SEAndroid_user_space

Iniciar

O processo init do Android é diferente das distribuições Linux padrão. O init do Android interpreta os comandos init.rc por conta própria, em vez de depender de um interpretador de shell. Por causa disso, o processo de inicialização do Android é estendido para oferecer suporte a vários comandos SEAndroid que podem ser adicionados ao init.rc. Esses comandos incluem funções para definir rótulos de segurança e comandos para definir o modo SEAndroid. O init do Android foi modificado para carregar a política de segurança no início do processo de inicialização e também foi modificado para aplicar a política de segurança ao acessar as “propriedades” do sistema.

Dalvik / Zygote

No Android, os aplicativos são criados pelo processo Zygote. Zygote obtém o comando de “system_server” por meio de um soquete e, em seguida, invoca uma função em Dalvik para gerar um novo processo para aplicativos. Dalvik cria novos processos para aplicativos e define credenciais DAC apropriadas. SEAndroid modificou o Dalvik para definir o contexto de segurança do aplicativo, de forma que os aplicativos sejam rotulados de forma diferente do Zygote / Dalvik. O Zygote também foi modificado para definir o rótulo de segurança da interface de soquete que é usada para receber comandos para criar novos aplicativos. Esta interface de socket é restrita para que apenas system_server possa instruir o Zygote a gerar um novo processo.

Biônico

O Android não usa glibc. Em vez disso, ele tem sua própria implementação da biblioteca C, chamada Bionic. O Bionic foi estendido para fornecer suporte para definir e obter os atributos estendidos dos sistemas de arquivos. Atributos estendidos são usados ​​para armazenar rótulos de segurança para arquivos.

Gerenciador de pacotes

No SEAndroid, o Gerenciador de pacotes foi modificado para consultar o arquivo de política específico do Android “ mac_permissions.xml ” e decidir se as permissões solicitadas pelo aplicativo podem realmente ser concedidas a ele; a instalação do aplicativo será abortada se as permissões não puderem ser concedidas. Mais detalhes sobre isso são fornecidos na seção Instalação do aplicativo abaixo.

installd

O daemon “ installd ” no Android cria o diretório do aplicativo no momento da instalação do aplicativo. “ INSTALLD ” em SEAndroid é modificado para se referir a ““mac_permission.xml”e seapps_context arquivos de política” para determinar o contexto de segurança para a aplicação tentar ser instalado. Com base no contexto de segurança do aplicativo, installd rotula o diretório de dados do aplicativo apropriadamente para acesso futuro.

SEAndroid Operations
A seção a seguir descreve as operações realizadas pelo SEAndroid, desde a construção do Android até a execução do aplicativo Android.

Android Build
A ferramenta Android “ make_ext4fs” é usada para criar imagens Android (system.img, userdata.img etc) a partir de binários compilados. Esta ferramenta é modificada para SEAndroid para definir rótulos de segurança iniciais de arquivos na partição “ sistema ” e “dados do usuário ”. “ Make_ext4fs ” consulta a política SEAndroid “ file_contexts ” para criar rótulos de segurança iniciais. “ File_contexts ” também está incluído na imagem de recuperação para que os rótulos de segurança apropriados sejam aplicados após a atualização do sistema.

Android Boot
O init do Android é modificado para carregar as políticas de segurança. O contexto de segurança de “ init ” é explicitamente definido a partir de “ init.rc. ”SEAndroid definiu domínios separados para todos os serviços do sistema, então os processos do sistema iniciados pelo init são automaticamente transferidos para seu próprio domínio, de acordo com seus rótulos de segurança e regras de transição na política de segurança.

Instalação de aplicativo
SEAndroid introduziu um novo conceito de MAC em tempo de instalação . Essa abordagem fornece um mecanismo centralizado usado para controlar as permissões máximas que podem ser concedidas a um aplicativo. No Android, normalmente um usuário decide se ele ou ela está disposto a fornecer as permissões solicitadas pelo aplicativo, e o aplicativo só é instalado se o usuário estiver disposto a fornecer todas as permissões. No entanto, com SEAndroid, ” tempo de instalaçãoO MAC adiciona outra camada onde uma política é consultada para verificar se as permissões solicitadas podem ser atribuídas a um aplicativo, mesmo se o usuário estiver disposto a fornecer essas permissões. O aplicativo não será instalado se a permissão solicitada pelo aplicativo não puder ser concedida de acordo com a política de segurança. Esse mecanismo pode ser usado em dispositivos de nível corporativo para controlar melhor as permissões atribuídas aos aplicativos.

A política MAC de tempo de instalação é especificada em “ mac_permissions.xml. ”Com base no certificado de segurança e no nome do pacote do aplicativo,“ mac_permissions.xml ”fornece uma string“ seinfo ”para o aplicativo. No momento da instalação do aplicativo, o Android “Package Manager” consulta “mac_permissions.xml” para obter a string “seinfo” do aplicativo e verifica se as permissões solicitadas podem ser atribuídas ao aplicativo. A seguir está o formato de “mac_permissions.xml”:

mac_permissions_format
Após as verificações do MAC no momento da instalação, o aplicativo é instalado pelo Gerenciador de Pacotes de acordo com o procedimento padrão do Android. 
Após a instalação, o Gerenciador de pacotes instrui o “installd” a criar o diretório de “dados” para o aplicativo. 
SEAndroid modificou “ 
installd ” para usar “ 
seinfo ” para o aplicativo de “mac_permissions.xml” e informações de “ 
seapp_contexts ” para determinar o rótulo de segurança para o diretório de dados do aplicativo. 
Assim, “ 
installd ” pode criar o diretório de dados e rotulá-lo de acordo com as informações de “tipo” de “seapp_contexts”. 
O seguinte é um subconjunto do arquivo “seapp_context”:
seapp_context_file

Execução de Aplicativos
Conforme mencionado anteriormente, o Zygote no Android cria todos os processos de aplicativos. No momento da geração de um processo de aplicativo, o Zygote consulta o arquivo “ seapp_contexts ” para obter o nome de domínio para o processo de aplicativo. “ Seapp_contexts ” fornece domínio para o processo de aplicativo com base em “ seinfo ”, “ nome do pacote ”, “ nome de usuário ” do aplicativo.

SEAndroid MMAC
Além de trazer a facilidade SELinux de Controle de Acesso Obrigatório, SEAndroid adicionou o conceito de Middleware MAC (MMAC). MAC Médio, aplica funções de controle de acesso obrigatórias nas permissões IPC e Android. Alguns dos conceitos do MMAC já foram introduzidos anteriormente; a seção a seguir resumirá esses conceitos.

MAC em tempo de instalação

O MAC no momento da instalação atribui um valor “ seinfo ” a um aplicativo com base no nome do pacote do aplicativo e no certificado com o qual o aplicativo foi assinado. “ Seinfo ” para o aplicativo, junto com as informações em “seapp_contexts,” é usado para decidir sobre o contexto de segurança para o aplicativo.

Firewall de intenção
Com base na política de segurança, o Intent Firewall permite que as intenções do Android sejam bloqueadas para entrega a determinados aplicativos. Isso pode ser usado para impedir que aplicativos não confiáveis ​​obtenham informações sobre eventos específicos do sistema, que geralmente são transmitidos como intents. O Intent Firewall está em andamento, mas torna obsoleto o “ Intent MAC ” anterior do SEAndroid.

Enterprise Ops
O Enterprise Ops foi desenvolvido com base no Android AppOps, que foi introduzido no Android 4.3. O Enterprise Ops fornece suporte para controlar as operações de tempo de execução por aplicativos. “Enterprise Ops” agrupa os aplicativos com base em “ seinfo” e em “eops.xml”. Ele decide quais operações devem ser bloqueadas para aplicativos.

Política SEAndroid
Os arquivos de política SEAndroid usam a mesma sintaxe dos arquivos de política SELinux e estão disponíveis no diretório external / sepolicy na árvore de origem do Android. Os arquivos de política são compilados como binários “ sepolicy ” usando o compilador de política “ checkpolicy. ”Arquivo de política“ sepolicy ” , “ file_contexts ”e“ seapp_contexts ”são copiados no dispositivo Android em“ /. ” “ Mac_permissions.xml” é copiado para / system / etc / security .

SEAndroid

O Android permite que os fornecedores de dispositivos adicionem ou substituam as definições de AOSP. Portanto, um fornecedor de dispositivo pode configurar as variáveis ​​BOARD_SEPOLICY_UNION e / ou BOARD_SEPOLICY_REPLACE em BoardConfig.mk para adicionar ou substituir as políticas AOSP conforme necessário. Os diretórios que precisam ser pesquisados ​​por políticas específicas do fornecedor podem ser definidos usando BOARD_SEPOLICY_DIRS em BoardConfig.mk.

O status atual do SEAndroid no AOSP
A partir do Android 4.4, o SEAndroid está no modo “obrigatório”. No entanto, em outubro de 2014, apenas 4 domínios foram confinados, enquanto o restante foi definido no modo “permissivo”. Atualmente, no mestre AOSP, todos os domínios, exceto “kernel”, “init” e “init_shell”, estão no domínio confinado. Mesmo o processo no domínio “não confinado” não pode executar todas as operações, pois o processo do domínio “não confinado” não tem permissão para executar arquivos fora do diretório “/ sistema”.

O AOSP não inclui a maioria dos mecanismos MMAC, incluindo o MAC no momento da instalação. No entanto, “mac_permissions.xml” está sendo usado para atribuir “seinfo” a aplicativos com base em sua assinatura.

LEAVE A REPLY

Please enter your comment!
Please enter your name here