O Google está comprometido em promover a equidade racial para as comunidades negras. Veja como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Personalizando o SELinux

Depois de integrar o nível básico da funcionalidade do SELinux e analisar os resultados, você poderá adicionar suas próprias configurações de política para cobrir suas personalizações no sistema operacional Android. Essas políticas ainda devem atender aos requisitos do programa Compatibilidade Android e não devem remover as configurações padrão do SELinux.

Os fabricantes não devem remover a política existente do SELinux. Caso contrário, eles correm o risco de interromper a implementação do Android SELinux e os aplicativos que ele governa. Isso inclui aplicativos de terceiros que provavelmente precisarão ser aprimorados para serem compatíveis e operacionais. Os aplicativos não precisam de modificação para continuar funcionando nos dispositivos habilitados para SELinux.

Ao iniciar a personalização do SELinux, lembre-se de:

  • Escreva a política do SELinux para todos os novos daemons
  • Use domínios predefinidos sempre que apropriado
  • Atribua um domínio a qualquer processo gerado como um serviço init
  • Familiarize-se com as macros antes de escrever políticas
  • Enviar alterações à política principal ao AOSP

E lembre-se de não:

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

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

O SELinux usa uma abordagem da lista de permissões, o que significa que todo acesso deve ser explicitamente permitido na política para ser concedido. Como a política padrão do SELinux do Android já suporta o Android Open Source Project, você não precisa modificar as configurações do SELinux de nenhuma maneira. Se você personalizar as configurações do SELinux, tome muito cuidado para não quebrar os aplicativos existentes. Para começar:

  1. Use o kernel Android mais recente .
  2. Adote o princípio do menor privilégio .
  3. Aborde apenas suas próprias adições ao Android. A política padrão funciona automaticamente com a base de código do Android Open Source Project .
  4. Compartir os componentes de software em módulos que realizam tarefas singulares.
  5. Crie políticas SELinux que isolem essas tarefas de funções não relacionadas.
  6. Coloque essas políticas nos arquivos *.te (a extensão dos arquivos de origem da política do SELinux) no diretório /device/ manufacturer / device-name /sepolicy e use BOARD_SEPOLICY variáveis BOARD_SEPOLICY para incluí-las em sua compilação.
  7. Tornar novos domínios permissivos inicialmente. Isso é feito usando uma declaração permissiva 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 negação adicional aparecer nas construções de depuração do usuário.

Depois de integrar sua alteração de política do SELinux, adicione uma etapa ao seu fluxo de trabalho de desenvolvimento para garantir a compatibilidade do SELinux no futuro. Em um processo ideal de desenvolvimento de software, a política do SELinux muda apenas quando o modelo de software é alterado e não a implementação real.

Ao começar a personalizar o SELinux, primeiro audite suas adições ao Android. Se você adicionou um componente que conduz uma nova função, verifique se ele cumpre a política de segurança do Android, bem como qualquer política associada criada pelo OEM, antes de ativar o modo de imposição.

Para evitar problemas desnecessários, é melhor ser overbroad e supercompatível do que muito restritivo e incompatível, o que resulta em funções quebradas do dispositivo. Por outro lado, se suas alterações beneficiarem outras pessoas, você deve enviar as modificações para a política padrão do SELinux como um patch . Se o patch for aplicado à política de segurança padrão, você não precisará fazer essa alteração a cada nova versão do Android.

Exemplos de declarações de política

O SELinux é baseado na linguagem de computador M4 e, portanto, suporta uma variedade de macros para economizar tempo.

No exemplo a seguir, todos os domínios têm acesso concedido para ler ou gravar em /dev/null e ler em /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 };

Essa mesma declaração pode ser escrita com as macros SELinux *_file_perms (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;

Política de exemplo

Aqui está um exemplo completo de política para DHCP, que examinamos abaixo:

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 dissecar o exemplo:

Na primeira linha, a declaração de tipo, o daemon DHCP herda da política de segurança básica ( domain ). Nos exemplos de instruções anteriores, 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 do 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 de net , como ler e gravar pacotes TCP, comunicar-se por soquetes e realizar solicitações de DNS.

Na linha, allow dhcp proc_net:file write; , a política declara que o DHCP pode gravar em arquivos específicos em /proc . Esta linha demonstra a rotulagem refinada de arquivos do SELinux. Ele 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 começando com allow dhcp netd:fd use; mostra como os aplicativos podem interagir entre si. A política diz que o DHCP e o netd podem se comunicar por meio de descritores de arquivos, arquivos FIFO, soquetes de datagrama e soquetes de fluxo UNIX. O DHCP pode apenas ler e gravar nos soquetes de datagrama e soquetes de fluxo UNIX e não criar ou abri-los.

Controles disponíveis

Classe Permissão
Arquivo
ioctl read write create getattr setattr lock relabelfrom relabelto append
unlink link rename execute swapon quotaon mounton
diretório
add_name remove_name reparent search rmdir open audit_access execmod
tomada
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
sistema de arquivo
mount remount unmount getattr relabelfrom relabelto transition associate
quotamod quotaget
processo
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
segurança
compute_av compute_create compute_member check_context load_policy
compute_relabel compute_user setenforce setbool setsecparam setcheckreqprot
read_policy
capacidade
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

MAIS

E MAIS

regras nunca permitidas

neverallow regras SELinux neverallow proíbem comportamentos que nunca devem ocorrer. Com o teste de compatibilidade , o SELinux neverallow regras sejam aplicadas em todos os dispositivos.

As diretrizes a seguir destinam-se a ajudar os fabricantes a evitar erros relacionados a regras de neverallow durante a personalização. Os números das regras usados ​​aqui correspondem ao Android 5.1 e estão sujeitos a alterações mediante o lançamento.

Regra 48: neverallow { domain -debuggerd -vold -dumpstate -system_server } self:capability sys_ptrace;
Veja a página de manual do ptrace . O sys_ptrace capacidade confere a capacidade de ptrace qualquer processo, que permite um grande controlo sobre os outros processos e deve pertencer apenas aos componentes do sistema, descritos designados na regra. A necessidade desse recurso geralmente indica a presença de algo que não se destina a construções ou funcionalidades voltadas para o usuário que não são necessárias. Retire o componente desnecessário.

Regra 76: neverallow { domain -appdomain -dumpstate -shell -system_server -zygote } { file_type -system_file -exec_type }:file execute;
Esta regra tem como objetivo impedir a execução de código arbitrário no sistema. Especificamente, ele afirma que apenas o código no /system é executado, o que permite garantias de segurança graças a mecanismos como inicialização verificada. Freqüentemente, a melhor solução ao encontrar um problema com essa regra de neverallow é mover o código neverallow para a partição /system .

Personalizando o SEPolicy no Android 8.0 ou superior

Esta seção fornece diretrizes para a política do SELinux do fornecedor no Android 8.0 e superior, incluindo detalhes sobre as extensões SEPolicy e SEPolicy do Android Open Source Project (AOSP). Para obter mais informações sobre como a política do SELinux é mantida compatível entre 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 poderiam adicionar uma política ao BOARD_SEPOLICY_DIRS , incluindo a política destinada a aumentar a política do AOSP em diferentes tipos de dispositivos. No Android 8.0 e superior, adicionar uma política a BOARD_SEPOLICY_DIRS coloca a política apenas na imagem do fornecedor.

No Android 8.0 e superior, a política existe nos seguintes locais no AOSP:

  • sistema / sepolicy / público . Inclui política exportada para uso em política específica do fornecedor. Tudo vai para a infraestrutura de compatibilidade do Android 8.0. A política pública deve persistir nas versões para que você possa incluir qualquer coisa /public em sua política personalizada. Por esse motivo, o tipo de política que pode ser colocada em /public é mais restrito. Considere esta API de política exportada da plataforma: tudo o que lida com a interface entre /system e /vendor pertence aqui.
  • sistema / sepolicy / privado . Inclui a política necessária para o funcionamento da imagem do sistema, mas cuja política de imagem do fornecedor não deve ter conhecimento.
  • sistema / sepolicy / fornecedor . Inclui política para componentes que entram no /vendor mas existem na árvore da plataforma principal (não nos diretórios específicos do dispositivo). Esse é um artefato da distinção do sistema de construção entre dispositivos e componentes globais; conceitualmente, isso faz parte da política específica do dispositivo descrita abaixo.
  • dispositivo / manufacturer / device-name / sepolicy . Inclui política específica do dispositivo. Também inclui personalizações de dispositivo para a política, que no Android 8.0 e superior corresponde à política para componentes na imagem do fornecedor.

Cenários de política suportados

Nos dispositivos iniciados com Android 8.0 e superior, a imagem do fornecedor deve funcionar com a imagem do sistema OEM e a imagem do sistema AOSP de referência fornecida pelo Google (e passar o CTS nessa imagem de referência). Esses requisitos garantem uma separação limpa entre a estrutura e o código do fornecedor. Esses dispositivos suportam os seguintes cenários.

extensões somente de imagem do fornecedor

Exemplo : Adicionando um novo serviço ao vndservicemanager partir da imagem do fornecedor que suporta processos da imagem do fornecedor.

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

suporte à imagem do fornecedor para trabalhar com o AOSP

Exemplo : Adicionando um novo processo (registrado no hwservicemanager partir da imagem do fornecedor) que implementa um HAL definido pelo AOSP.

Assim como nos dispositivos iniciados com versões anteriores do Android, execute a personalização específica do device/ manufacturer / device-name /sepolicy em device/ manufacturer / device-name /sepolicy . A política exportada como parte do system/sepolicy/public/ está disponível para uso e é enviada como parte da política do fornecedor. Os tipos e atributos da política pública podem ser usados ​​em novas regras que determinam interações com os novos bits específicos do fornecedor, sujeitos às restrições neverallow fornecidas. Como no caso do fornecedor, a nova política aqui não será atualizada como parte de uma OTA somente de estrutura e estará presente na política combinada em um dispositivo com a imagem do sistema AOSP de referência.

extensões somente de imagem do sistema

Exemplo : Adicionando um novo serviço (registrado no servicemanager) que é acessado apenas por outros processos da imagem do sistema.

Adicione esta política ao system/sepolicy/private . Você pode adicionar processos ou objetos extras para habilitar a funcionalidade em uma imagem do sistema parceiro, desde que esses novos bits não precisem interagir com novos componentes na imagem do fornecedor (especificamente, esses processos ou objetos devem funcionar totalmente sem política da imagem do fornecedor) . A política exportada por system/sepolicy/public está disponível aqui, assim como para extensões somente de imagem de fornecedor. Esta política faz parte da imagem do sistema e pode ser atualizada em uma OTA somente de estrutura, mas não estará presente ao usar a imagem do sistema AOSP de referência.

extensões de imagem de fornecedor que atendem a componentes AOSP estendidos

Exemplo: Um novo 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 o sistema e o fornecedor deve ser incluída no diretório device/ manufacturer / device-name /sepolicy enviado na partição do fornecedor. Isso é semelhante ao cenário acima de adicionar suporte à imagem do fornecedor para funcionar com a imagem AOSP de referência, exceto que os componentes AOSP modificados também podem exigir uma política adicional para operar adequadamente com o restante da partição do sistema (o que é bom, desde que ainda os rótulos públicos do tipo AOSP).

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

extensões de imagem do sistema que acessam apenas interfaces AOSP

Exemplo: Um novo processo do sistema não AOSP deve acessar um HAL no qual o AOSP depende.

Isso é semelhante ao exemplo de extensão somente imagem do sistema , exceto que novos componentes do sistema podem interagir na interface do system/vendor . A política para o novo componente do sistema deve ser em system/sepolicy/private , o que é aceitável, desde que seja através de uma interface já estabelecida pela AOSP em system/sepolicy/public (ou seja, os tipos e atributos necessários para a funcionalidade existem). Embora a política possa ser incluída na política específica do dispositivo, ela não poderá usar outros tipos de system/sepolicy/private ou alterar (de qualquer maneira que afete a política) como resultado de uma atualização somente da estrutura. A política pode ser alterada em uma OTA somente de estrutura, mas não estará presente ao usar uma imagem do sistema AOSP (que também não terá o novo componente do sistema).

extensões de imagem de fornecedor que atendem a novos componentes do sistema

Exemplo: Adicionando um novo HAL não AOSP para uso por um processo do cliente sem um análogo AOSP (e, portanto, requer seu próprio domínio).

Semelhante ao exemplo de extensões AOSP , a política para interações entre o sistema e o fornecedor deve estar no diretório 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ê pode adicionar novos tipos públicos que estendem a política em system/sepolicy/public ; isso deve ser feito apenas em adição à política AOSP existente, ou seja, não remova a política pública AOSP. Os novos tipos públicos podem então ser usados ​​para política em system/sepolicy/private e em device/ manufacturer / device-name /sepolicy .

Lembre-se de que todas as inclusões em system/sepolicy/public adicionam complexidade ao expor uma nova garantia de compatibilidade que deve ser rastreada em um arquivo de mapeamento e que está sujeita a outras restrições. Somente novos tipos e regras de permissão correspondentes podem ser adicionados ao system/sepolicy/public ; atributos e outras declarações de política não são suportados. Além disso, novos tipos públicos não podem ser usados ​​para rotular objetos diretamente na política /vendor .

Cenários de política não suportados

Os dispositivos iniciados com Android 8.0 e superior não suportam o seguinte cenário e exemplos de políticas.

Extensões adicionais à imagem do sistema que precisam de permissão para novos componentes de imagem do fornecedor após um OTA somente de estrutura

Exemplo: Um novo processo do sistema não AOSP, que requer seu próprio domínio, é adicionado na próxima versão do Android e precisa de acesso a um novo HAL não AOSP.

Semelhante à nova interação do sistema (não AOSP) e componentes do fornecedor , exceto que o novo tipo de sistema é introduzido em uma OTA somente de estrutura. Embora o novo tipo possa ser adicionado à política em system/sepolicy/public , a política de fornecedor existente não tem conhecimento do novo tipo, pois está acompanhando apenas a política pública do sistema Android 8.0. O AOSP lida com isso expondo recursos fornecidos pelo fornecedor por meio de um atributo (por exemplo, atributo hal_foo ), mas como extensões de parceiro de atributo não são suportadas em system/sepolicy/public , esse método não está disponível na política do fornecedor. O acesso deve ser fornecido por um tipo público já existente.

Exemplo: Uma alteração em um processo do sistema (AOSP ou não-AOSP) deve alterar a forma como interage com o novo componente do fornecedor não-AOSP.

A política na imagem do sistema deve ser escrita sem o conhecimento de personalizações específicas do fornecedor. A política referente a interfaces específicas no AOSP é, portanto, exposta por meio de atributos em system / sepolicy / public, para que a política do fornecedor possa aceitar a futura política do sistema que utiliza esses atributos. No entanto, extensões de atributo em system/sepolicy/public não são suportadas , portanto, todas as políticas que determinam como os componentes do sistema interagem com os novos componentes do fornecedor (e que não são tratadas por atributos já presentes no system/sepolicy/public AOSP system/sepolicy/public ) devem estar no device/ manufacturer / device-name /sepolicy . Isso significa que os tipos de sistema não podem alterar o acesso permitido aos tipos de fornecedores como parte de uma OTA somente de estrutura.