Como personalizar o SELinux

Depois de integrar o nível básico da funcionalidade do SELinux e analisar os resultados, adicione suas próprias configurações de política suas personalizações no sistema operacional Android. Essas políticas ainda precisam conheça o Programa de compatibilidade do Android e não pode remover as configurações padrão do SELinux.

Os fabricantes não devem remover a política de SELinux existente. Caso contrário, eles correrá o risco de corromper a implementação do SELinux do Android e os aplicativos governa. Isso inclui aplicativos de terceiros que provavelmente precisarão ser para garantir a conformidade e a operação. Os aplicativos não devem exigir para continuar funcionando em dispositivos com SELinux.

Ao personalizar o SELinux, lembre-se de:

• Escrever uma política de SELinux para todos os novos daemons
• Use domínios predefinidos sempre que apropriado
• Atribuir um domínio a qualquer processo gerado como um serviço init
• Familiarize-se com as macros antes de escrever a política
• Enviar mudanças na política principal para o AOSP

E não se esqueça de:

• Criar política incompatível
• Permitir a personalização da política do usuário final
• Permitir personalizações de política de MDM
• assustar os usuários com violações da política;
• Adicionar backdoors

Consulte a seção Recursos de segurança do kernel da No Android Documento de definição de compatibilidade para requisitos específicos.

O SELinux usa uma abordagem de lista branca, o que significa que todo acesso deve ser explicitamente permitida na política para ser concedido. Como o SELinux padrão do Android política já for compatível com o Android Open Source Project, não será necessário modificar as configurações do SELinux. Se você personalizar as configurações do SELinux, tome muito cuidado para não corromper os aplicativos atuais. Para começar, faça o seguinte:

1. Use o Android mais recente kernel.
2. Adote o princípio de privilégio mínimo.
3. Resolva apenas suas próprias adições ao Android. A política padrão funciona com Android Open Source Project automaticamente.
4. Compartimentalizar componentes de software em módulos que conduzem tarefas.
5. Criar políticas de SELinux que isolam essas tarefas de tarefas não relacionadas .
6. Coloque essas políticas em arquivos *.te (a extensão para SELinux arquivos de origem de políticas) no /device/manufacturer/device-name/sepolicy e usar variáveis BOARD_SEPOLICY para incluí-los no seu build.
7. Torne os novos domínios permissivos inicialmente. Isso é feito com o uso de uma declaração no arquivo .te do domínio.
8. Analise os resultados e refine suas definições de domínio.
9. Remova a declaração permissiva quando nenhuma outra negação aparecer no userdebug builds.

Depois de integrar a mudança de política do SELinux, adicione uma etapa ao de desenvolvimento para garantir a compatibilidade com SELinux de agora em diante. Em um ideal processo de desenvolvimento de software, a política do SELinux muda somente quando o software mudanças no modelo, e não na implementação real.

Ao começar a personalizar o SELinux, primeiro faça uma auditoria das suas adições ao Android. Se você adicionou um componente que realiza uma nova função, certifique-se de que o componente atenda à política de segurança do Android, bem como qualquer política associada criada pelo o OEM antes de ativar o modo de aplicação.

Para evitar problemas desnecessários, é melhor ser amplo demais e tem compatibilidade demais do que muito restritivo e incompatível, o que resulta em problemas nas funções do dispositivo. Da mesma forma, se suas mudanças beneficiarão outros, você deverá envie as modificações da política do SELinux padrão como patch. Se o patch for aplicada à política de segurança padrão, não será preciso fazer essa alteração a cada nova versão do Android.

Exemplos de instruções de política

O SELinux é baseado na M4 (link em inglês) linguagem de computador e, por isso, oferece suporte a várias macros para economizar tempo.

No exemplo a seguir, todos os domínios recebem acesso de leitura ou gravar em /dev/null e ler de /dev/zero.

# Allow read / write access to /dev/null
allow domain null_device:chr_file { getattr open read ioctl lock append write};

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file { getattr open read ioctl lock };

A mesma instrução pode ser escrita com SELinux *_file_perms macros (abreviação):

# Allow read / write access to /dev/null
allow domain null_device:chr_file rw_file_perms;

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file r_file_perms;

Exemplo de política

Veja abaixo um exemplo completo de política para DHCP:

type dhcp, domain;
permissive dhcp;
type dhcp_exec, exec_type, file_type;
type dhcp_data_file, file_type, data_file_type;

init_daemon_domain(dhcp)
net_domain(dhcp)

allow dhcp self:capability { setgid setuid net_admin net_raw net_bind_service
};
allow dhcp self:packet_socket create_socket_perms;
allow dhcp self:netlink_route_socket { create_socket_perms nlmsg_write };
allow dhcp shell_exec:file rx_file_perms;
allow dhcp system_file:file rx_file_perms;
# For /proc/sys/net/ipv4/conf/*/promote_secondaries
allow dhcp proc_net:file write;
allow dhcp system_prop:property_service set ;
unix_socket_connect(dhcp, property, init)

type_transition dhcp system_data_file:{ dir file } dhcp_data_file;
allow dhcp dhcp_data_file:dir create_dir_perms;
allow dhcp dhcp_data_file:file create_file_perms;

allow dhcp netd:fd use;
allow dhcp netd:fifo_file rw_file_perms;
allow dhcp netd:{ dgram_socket_class_set unix_stream_socket } { read write };
allow dhcp netd:{ netlink_kobject_uevent_socket netlink_route_socket
netlink_nflog_socket } { read write };

Vamos analisar o exemplo:

Na primeira linha, a declaração do tipo, o daemon DHCP herda da política de segurança básica (domain). Da declaração anterior exemplos, o DHCP pode ler e gravar em /dev/null.

Na segunda linha, o DHCP é identificado como um domínio permissivo.

Na linha init_daemon_domain(dhcp), a política declara que o DHCP é gerado a partir de init e tem permissão para se comunicar com ele.

Na linha net_domain(dhcp), a política permite que o DHCP use funcionalidade de rede comum do domínio net, como leitura gravação de pacotes TCP, comunicação por soquetes e realização de solicitações.

Na linha allow dhcp proc_net:file write;, a política declara O DHCP pode gravar em arquivos específicos em /proc. Esta linha demonstra Rotulagem refinada de arquivos do SELinux. Ela usa o rótulo proc_net. para limitar o acesso de gravação apenas aos arquivos em /proc/sys/net.

O bloco final do exemplo, que começa com allow dhcp netd:fd use; descreve como os aplicativos podem ter permissão para interagem entre si. A política determina que o DHCP e o netd podem se comunicar uns aos outros por meio de descritores de arquivo, arquivos FIFO, soquetes de datagrama e stream UNIX soquetes. O DHCP só pode ler e gravar nos soquetes de datagrama e UNIX e não os cria nem os abre.

Controles disponíveis

ioctl read write create getattr setattr lock relabelfrom relabelto append
unlink link rename execute swapon quotaon mounton

add_name remove_name reparent search rmdir open audit_access execmod

ioctl read write create getattr setattr lock relabelfrom relabelto append bind
connect listen accept getopt setopt shutdown recvfrom sendto recv_msg send_msg
name_bind

mount remount unmount getattr relabelfrom relabelto transition associate
quotamod quotaget

fork transition sigchld sigkill sigstop signull signal ptrace getsched setsched
getsession getpgid setpgid getcap setcap share getattr setexec setfscreate
noatsecure siginh setrlimit rlimitinh dyntransition setcurrent execmem
execstack execheap setkeycreate setsockcreate

compute_av compute_create compute_member check_context load_policy
compute_relabel compute_user setenforce setbool setsecparam setcheckreqprot
read_policy

chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap
linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock
ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin
sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write
audit_control setfcap

regras de nunca permitir

As regras neverallow do SELinux proíbem comportamentos que nunca devem ocorrer. Com os testes de compatibilidade, As regras neverallow do SELinux agora são aplicadas em todos os dispositivos.

As diretrizes a seguir ajudam os fabricantes a evitar erros relacionadas às regras neverallow durante a personalização. Os números das regras usados aqui correspondem ao Android 5.1 e estão sujeitos a mudanças de acordo com a versão.

Regra 48: neverallow { domain -debuggerd -vold -dumpstate -system_server } self:capability sys_ptrace;
Veja a página do manual de ptrace. O sys_ptrace concede a capacidade de ptrace qualquer processo, o que permite muito de controle sobre outros processos e devem pertencer apenas ao sistema conforme descrito na regra. A necessidade dessa capacidade geralmente indica a presença de algo que não se destina a builds voltados para o usuário ou que não é necessária. Remova o componente desnecessário.

Regra 76: neverallow { domain -appdomain -dumpstate -shell -system_server -zygote } { file_type -system_file -exec_type }:file execute;
O objetivo dessa regra é evitar a execução de código arbitrário no sistema. Especificamente, ele declara que apenas o código em /system é executado. que garante a segurança graças a mecanismos como a Inicialização verificada. Muitas vezes, a melhor solução ao ter um problema com isso A regra neverallow é mover o código com problemas para a /system.

Como personalizar o SEPolicy no Android 8.0 ou versões mais recentes

Esta seção fornece diretrizes para a política do SELinux do fornecedor no Android 8.0 e versões mais recentes, incluindo detalhes sobre a SEPolicy do Android Open Source Project (AOSP) e Extensões SEPolicy. Para mais informações sobre como a política do SELinux é mantida compatíveis com várias partições e versões do Android, consulte Compatibilidade.

Posicionamento da política

No Android 7.0 e versões anteriores, os fabricantes de dispositivos podiam adicionar políticas ao BOARD_SEPOLICY_DIRS, incluindo a política criada para ampliar a política do AOSP em diferentes tipos de dispositivos. No Android 8.0 e versões mais recentes, adicionar uma política ao BOARD_SEPOLICY_DIRS coloca a política apenas no fornecedor imagem.

No Android 8.0 e versões mais recentes, a política existe nos seguintes locais no AOSP:

• system/sepolicy/public. Inclui política exportada para uso políticas específicas do fornecedor. Tudo o que você precisa para o Android 8.0 infraestrutura de compatibilidade. A política pública é mantida em todas as versões para que você possa incluir qualquer coisa /public na sua política personalizada. Por isso, o tipo de política que pode ser colocado em /public é mais restritas. Considere esta API de política exportada da plataforma: qualquer item que lida com a interface entre /system e /vendor pertence aqui.
• system/sepolicy/private. Inclui a política necessária para o funcionamento da imagem do sistema, mas de qual política de imagem do fornecedor deve não têm conhecimento.
• system/sepolicy/vendor. Inclui uma política para componentes que vão em /vendor, mas existem na árvore de plataforma principal (não específicos do dispositivo). Isso é um artefato do sistema de build distinção entre dispositivos e componentes globais; conceitualmente, é uma parte da política específica do dispositivo descrita abaixo.
• device/manufacturer/device-name/sepolicy. Inclui uma política específica do dispositivo. Também inclui personalizações do dispositivo para política, que, no Android 8.0 e versões mais recentes, corresponde à política de componentes na imagem do fornecedor.

No Android 11 e versões mais recentes, as partições system_ext e produto também podem incluir específicas de partição. As políticas do system_ext e de produtos também estão divididas em público e privado, e os fornecedores podem usar os atributos de system_ext e como a do sistema.

• SYSTEM_EXT_PUBLIC_SEPOLICY_DIRS: Inclui política exportada para na política específica do fornecedor. Instalado na partição system_ext.
• SYSTEM_EXT_PRIVATE_SEPOLICY_DIRS: Inclui a política necessária para o funcionamento da imagem system_ext, mas de qual fornecedor de imagem a política não devem ter conhecimento. Instalado na partição system_ext.
• PRODUCT_PUBLIC_SEPOLICY_DIRS: Inclui política exportada para na política específica do fornecedor. Instalada na partição do produto.
• PRODUCT_PRIVATE_SEPOLICY_DIRS: Inclui a política necessária para o funcionamento da imagem do produto, mas de qual fornecedor de política de imagem não deve ter conhecimento. Instalada na partição do produto.

Cenários de políticas compatíveis

Em dispositivos lançados com o Android 8.0 e versões mais recentes, a imagem do fornecedor precisa funcionar com a imagem do sistema do OEM e a imagem do sistema AOSP de referência fornecidas pelo Google (e passe o CTS nesta imagem de referência). Esses requisitos garantem um ambiente limpo separação entre o framework e o código do fornecedor. Esses dispositivos dão suporte à cenários a seguir.

extensões somente de imagem do fornecedor

Exemplo: adicionar um novo serviço ao domínio vndservicemanager da imagem do fornecedor que dá suporte aos processos da imagem do fornecedor.

Assim como nos dispositivos lançados com versões anteriores do Android, adicione uma configuração personalização device/manufacturer/device-name/sepolicy: Nova política que rege como os componentes do fornecedor interagem (apenas) com outros fornecedores componentes devem envolver tipos presentes apenas em device/manufacturer/device-name/sepolicy. A política escrita aqui permite que o código no fornecedor funcione e não será atualizada como parte de OTA somente no framework e vai estar presente na política combinada de um dispositivo com a imagem do sistema AOSP de referência.

que o suporte a imagens de fornecedores funcione com o AOSP

Exemplo: adicionar um novo processo (registrado em hwservicemanager da imagem do fornecedor) que implementa uma HAL definida pelo AOSP.

Assim como em dispositivos lançados com versões anteriores do Android, execute personalização específica do dispositivo device/manufacturer/device-name/sepolicy: A política exportada como parte do system/sepolicy/public/ está disponível para uso e é enviado como parte da política do fornecedor. Tipos e atributos de a política pública pode ser usada em novas regras que determinam as interações com as novas bits específicos do fornecedor, sujeitos aos neverallow fornecidos restrições. Assim como no caso exclusivo de fornecedores, a nova política aqui não será atualizada. como parte de uma agência de viagens on-line somente para a estrutura e estarão presentes na política combinada com a imagem do sistema AOSP de referência.

extensões somente de imagem do sistema

Exemplo: adicionar um novo serviço (registrado no servicemanager) que é acessado somente por outros processos pela imagem do sistema.

Adicione essa política a system/sepolicy/private. Você pode adicionar mais processos ou objetos para ativar a funcionalidade em uma imagem de sistema de parceiro, desde que Essas partes não precisam interagir com novos componentes na imagem do fornecedor. (especificamente, tais processos ou objetos devem funcionar totalmente sem a política da a imagem do fornecedor). A política exportada pelo system/sepolicy/public é disponíveis aqui assim como para extensões somente de imagem de fornecedores. Esta política é parte da imagem do sistema e pode ser atualizado em uma OTA somente para o framework, mas não estar presente ao usar a imagem do sistema AOSP de referência.

imagem-do-fornecedor extensões que disponibilizam componentes estendidos do AOSP

Exemplo:uma nova HAL não AOSP para uso por clientes estendidos que também existem na imagem do sistema AOSP (como um system_server estendido).

A política de interação entre sistema e fornecedor deve ser incluída no device/manufacturer/device-name/sepolicy enviado na partição do fornecedor. Isso é semelhante ao cenário acima, em que o suporte de imagens de fornecedores é adicionado ao trabalho. com a imagem do AOSP de referência, exceto que os componentes do AOSP modificados também podem exigem políticas adicionais para funcionar corretamente com o restante do sistema (o que está correto, desde que ainda tenham o tipo AOSP público rótulos).

Política para interação de componentes públicos do AOSP com somente imagem do sistema As extensões precisam estar em system/sepolicy/private.

imagem do sistema extensões que acessam apenas interfaces AOSP

Exemplo:um novo processo do sistema não AOSP precisa acessar uma HAL no que o AOSP depende.

Isso é semelhante à função system-image-only exemplo de extensão, com a exceção de que novos componentes do sistema podem interagir na interface system/vendor. A política do novo componente do sistema precisa ir em system/sepolicy/private, o que é aceitável, desde que seja por uma interface já estabelecida pelo AOSP no system/sepolicy/public (ou seja, os tipos e atributos necessários para funcionalidade está disponível). Embora a política possa ser incluída em regras específicas do dispositivo, ela não poderá usar outras system/sepolicy/private ou mudanças (de qualquer maneira que afete a política) como resultado de uma implementação apenas atualizar. A política poderá ser alterada em uma OTA somente para a estrutura, mas não será presente ao usar uma imagem do sistema AOSP (que não terá o novo sistema ).

imagem-do-fornecedor extensões que exibem novos componentes do sistema

Exemplo:adicionar uma nova HAL não AOSP para ser usada por um processo do cliente sem um análogo do AOSP (e, portanto, exige um domínio próprio).

Semelhante às extensões do AOSP exemplo, a política para interações entre o sistema e o fornecedor deve ir no device/manufacturer/device-name/sepolicy enviado na partição do fornecedor (para garantir que a política do sistema não tenha conhecimento de detalhes específicos do fornecedor). Você podemos adicionar novos tipos públicos que estendem a política em system/sepolicy/public isso deve ser feito apenas além política do AOSP atual, ou seja, não remover a política pública do AOSP. O novo perfil tipos podem ser usados para a política em system/sepolicy/private e em device/manufacturer/device-name/sepolicy.

Lembre-se de que cada adição a system/sepolicy/public adiciona complexidade ao expor uma nova garantia de compatibilidade que deve ser rastreada em um e que está sujeito a outras restrições. Apenas novos tipos e as regras de permissão correspondentes podem ser adicionadas em system/sepolicy/public; atributos e outras instruções de política não são aceitos. Além disso, os novos tipos públicos não podem ser usados para rotular diretamente objetos na /vendor.

Cenários de política sem suporte

Os dispositivos lançados com o Android 8.0 e versões mais recentes não são compatíveis com o seguinte: o cenário atual da política e exemplos.

Adicional extensões à imagem do sistema que precisam de permissão para novos componentes de imagem do fornecedor depois de um OTA somente para o framework,

Exemplo : um novo processo de sistema não AOSP, que exige o próprio foi adicionado na próxima versão do Android e precisa de acesso a um novo HAL que não é do AOSP.

Semelhante a novo interação com componentes do sistema e do fornecedor (não AOSP), exceto pelo novo sistema tipo é introduzido em uma OTA somente para framework. O novo tipo pode ser adicionado à política system/sepolicy/public, a política do fornecedor atual não tem conhecimento do novo tipo, já que ele rastreia apenas a política pública do sistema Android 8.0. O AOSP lida com isso expondo os recursos fornecidos pelo fornecedor por meio de um atributo (por exemplo, hal_foo), mas, como as extensões de parceiros de atributo não são suportado em system/sepolicy/public, esse método não está disponível para política de fornecedores. O acesso precisa ser fornecido por um tipo público existente anteriormente.

Exemplo : uma mudança em um processo do sistema (AOSP ou não AOSP) precisa mudar a forma como ele interage com um novo componente de fornecedor não AOSP.

A política sobre a imagem do sistema precisa ser escrita sem conhecimento de requisitos personalizações de fornecedor. Portanto, a política sobre interfaces específicas no AOSP é expostos por atributos em system/sepolicy/public para que a política do fornecedor possa ativar a política do sistema futuro que usa esses atributos. No entanto, as extensões de atributo em system/sepolicy/public não estão têm suporte, então todas as políticas que determinam como os componentes do sistema interagem com novos componentes de fornecedores (e que ainda não são tratados por atributos presentes no system/sepolicy/public do AOSP) precisam estar no device/manufacturer/device-name/sepolicy. Isso significa que os tipos de sistema não podem mudar o acesso permitido aos tipos de fornecedores como parte de uma OTA somente para framework.