O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Implementando SELinux

O SELinux é configurado para negar padrão, o que significa que cada acesso único para o qual ele tem um gancho no kernel deve ser explicitamente permitido pela política. Isso significa que um arquivo de política é composto por uma grande quantidade de informações sobre regras, tipos, classes, permissões e muito mais. Uma consideração completa do SELinux está fora do escopo deste documento, mas um entendimento de como escrever regras de política agora é essencial ao criar novos dispositivos Android. Já existe uma grande quantidade de informações disponíveis sobre o SELinux. Consulte a documentação de apoio para recursos sugeridos.

Arquivos-chave

Para habilitar SELinux, integrar o mais recente Android do kernel e, em seguida, incorporar os arquivos encontrados no sistema / sepolicy diretório. Quando compilados, esses arquivos constituem a política de segurança do kernel SELinux e cobrem o sistema operacional upstream Android.

Em geral, você não deve modificar os system/sepolicy arquivos diretamente. Em vez disso, adicionar ou editar seus próprios arquivos de políticas específicas do dispositivo no /device/ manufacturer / device-name /sepolicy diretório. No Android 8.0 e superior, as alterações feitas nesses arquivos devem afetar apenas a política no diretório do seu fornecedor. Para mais detalhes sobre a separação de sepolicy pública no Android 8.0 e superior, consulte Personalizando SEPolicy no Android 8.0+ . Independentemente da versão do Android, você ainda está modificando estes arquivos:

Arquivos de política

Arquivos que terminam com *.te são arquivos de origem política do SELinux, que definem os domínios e seus rótulos. Pode ser necessário criar novos arquivos de política em /device/ manufacturer / device-name /sepolicy , mas você deve tentar atualizar os arquivos existentes sempre que possível.

Arquivos de contexto

Arquivos de contexto são onde você especifica rótulos para seus objetos.

  • file_contexts etiquetas atribui a arquivos e é usado por vários componentes do espaço do usuário. Conforme você cria novas políticas, crie ou atualize este arquivo para atribuir novos rótulos aos arquivos. Para aplicar novas file_contexts , reconstruir a imagem do sistema de arquivos ou executar restorecon no arquivo para ser remarcado. Em upgrades, alterações ao file_contexts são automaticamente aplicadas ao sistema e partições userdata como parte do upgrade. As mudanças também podem ser aplicados automaticamente no upgrade para outras partições adicionando restorecon_recursive chamadas para a sua inicialização. board arquivo.rc após a partição foi montado leitura e escrita.
  • genfs_contexts atribui etiquetas para sistemas de arquivos, como o proc ou vfat que não suportam atributos estendidos. Esta configuração é carregada como parte da política do kernel, mas as alterações podem não ter efeito para inodes in-core, exigindo uma reinicialização ou desmontagem e remontagem do sistema de arquivos para aplicar totalmente a alteração. Rótulos específicos também podem ser atribuídos a montagens específicas, como vfat usando o context=mount opção.
  • property_contexts etiquetas atribui a propriedades do sistema Android para controlar os processos que pode configurá-los. Esta configuração é lido pelo init processo durante a inicialização.
  • service_contexts atribui etiquetas para Android encadernação serviços para controlar os processos que pode adicionar (registrar) e encontrar (lookup) uma referência aglutinante para o serviço. Esta configuração é lido pelo servicemanager processo durante a inicialização.
  • seapp_contexts etiquetas atribui aos processos de aplicação e /data/data diretórios. Esta configuração é lido pelo zygote processo em cada lançamento do aplicativo e por installd durante a inicialização.
  • mac_permissions.xml atribui um seinfo tag para aplicativos com base em sua assinatura e, opcionalmente, o nome do pacote. O seinfo tag pode, então, ser usado como uma chave na seapp_contexts arquivo para atribuir um rótulo específico para todas as aplicações com que seinfo tag. Esta configuração é lido por system_server durante a inicialização.

BoardConfig.mk makefile

Depois de editar ou adicionar arquivos de política e de contexto, actualizar o seu /device/ manufacturer / device-name /BoardConfig.mk makefile fazer referência ao sepolicy subdiretório e cada novo arquivo de política. Para mais informações sobre os BOARD_SEPOLICY variáveis, consulte system/sepolicy/README arquivo .

BOARD_SEPOLICY_DIRS += \
        <root>/device/manufacturer/device-name/sepolicy

BOARD_SEPOLICY_UNION += \
        genfs_contexts \
        file_contexts \
        sepolicy.te

Após a reconstrução, seu dispositivo é habilitado com SELinux. Agora pode personalizar suas políticas SELinux para acomodar suas próprias adições ao sistema operacional Android, como descrito no personalização ou verificar a configuração existente como coberto de validação .

Quando os novos arquivos de política e atualizações BoardConfig.mk estão em vigor, as novas configurações de política são automaticamente incorporadas ao arquivo de política do kernel final. Para mais informações sobre como sepolicy é construído no dispositivo, consulte Edifício sepolicy .

Implementação

Para começar a usar o SELinux:

  1. Ativar SELinux no kernel: CONFIG_SECURITY_SELINUX=y
  2. Alterar o parâmetro kernel_cmdline ou bootconfig de modo que:
    BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
    ou
    BOARD_BOOTCONFIG := androidboot.selinux=permissive
    Esta é apenas para o desenvolvimento inicial da política para o dispositivo. Depois de ter uma política de bootstrap inicial, remova este parâmetro para que seu dispositivo esteja aplicando ou falhará CTS.
  3. Inicialize o sistema em permissivo e veja quais negações são encontradas na inicialização:
    No Ubuntu 14.04 ou mais recente:
    adb shell su -c dmesg | grep denied | audit2allow -p out/target/product/BOARD/root/sepolicy
    
    no Ubuntu 12.04:
    adb pull /sys/fs/selinux/policy
    adb logcat -b all | audit2allow -p policy
    
  4. Avaliar a saída para avisos que se assemelham a init: Warning! Service name needs a SELinux domain defined; please fix! Veja Validação para obter instruções e ferramentas.
  5. Identifique dispositivos e outros novos arquivos que precisam de rotulagem.
  6. Use rótulos existentes ou novos para seus objetos. Olhada nas *_contexts arquivos para ver como as coisas foram previamente identificados e uso do conhecimento dos significados de etiqueta para atribuir um novo. Idealmente, este será um rótulo existente que se encaixará na política, mas às vezes um novo rótulo será necessário e regras para acesso a esse rótulo serão necessárias. Adicione seus rótulos aos arquivos de contexto apropriados.
  7. Identifique domínios / processos que devem ter seus próprios domínios de segurança. Provavelmente, você precisará escrever uma política completamente nova para cada um. Todos os serviços gerados a partir init , por exemplo, deve ter sua própria. Os comandos a seguir ajudam a revelar aqueles que permanecem em execução (mas TODOS os serviços precisam de tal tratamento):
    adb shell su -c ps -Z | grep init
    
    adb shell su -c dmesg | grep 'avc: '
    
  8. Comente init. device .rc para identificar eventuais domínios que não têm um tipo de domínio. Dê-lhes um domínio no início de seu processo de desenvolvimento para evitar a adição de regras de init ou de outro modo confundindo init acessos com aqueles que estão na sua própria política.
  9. Set up BOARD_CONFIG.mk usar BOARD_SEPOLICY_* variáveis. Veja o README no system/sepolicy para obter detalhes sobre como fazer essa configuração.
  10. Examine o init. device .rc e fstab. device arquivo e certifique-se cada uso de mount corresponde a um sistema de arquivos devidamente rotulados ou que um context= mount opção é especificada.
  11. Passe por cada negação e crie uma política SELinux para lidar com cada uma delas adequadamente. Veja os exemplos em Personalização .

Você deve começar com as políticas no AOSP e, em seguida, desenvolvê-las para suas próprias personalizações. Para mais informações sobre a estratégia de política e uma olhada em algumas dessas etapas, consulte Writing Política SELinux .

Casos de uso

Aqui estão alguns exemplos específicos de exploits a serem considerados ao criar seu próprio software e políticas SELinux associadas:

Symlinks - Porque links simbólicos aparecem como arquivos, eles são muitas vezes lido como arquivos, que podem levar a ataques. Por exemplo, alguns componentes privilegiadas, como init , alterar as permissões de determinados arquivos, por vezes, ser excessivamente aberta.

Os invasores podem então substituir esses arquivos por links simbólicos para o código que eles controlam, permitindo que o invasor sobrescreva arquivos arbitrários. Mas se você sabe que seu aplicativo nunca atravessará um link simbólico, você pode proibi-lo de fazer isso com o SELinux.

Arquivos de sistema - Considere a classe de arquivos de sistema que deve ser modificado apenas pelo servidor do sistema. Ainda assim, desde netd , init , e vold prazo como root, eles podem acessar os arquivos do sistema. Então, se netd ficou comprometida, poderia comprometer os arquivos e, potencialmente, o servidor do sistema em si.

Com o SELinux, você pode identificar esses arquivos como arquivos de dados do servidor do sistema. Portanto, o único domínio que tem acesso de leitura / gravação a eles é o servidor do sistema. Mesmo se netd ficou comprometida, não poderia mudar domínios para o domínio do servidor sistema e acessar esses arquivos de sistema, embora ele seja executado como root.

Dados App - Outro exemplo é a classe de funções que devem ser executados como root, mas não deve obter os dados de acesso de aplicativos. Isso é incrivelmente útil, pois podem ser feitas afirmações abrangentes, como certos domínios não relacionados aos dados do aplicativo serem proibidos de acessar a Internet.

setattr - Para comandos como chmod e chown , você poderia identificar o conjunto de arquivos onde o domínio associado pode realizar setattr . Qualquer coisa fora disso pode ser proibida nessas alterações, mesmo pelo root. Portanto, um aplicativo pode executar chmod e chown contra aqueles rotulados app_data_files mas não shell_data_files ou system_data_files .