Embora a pergunta seja antiga, ela continua aparecendo sobre as perguntas Não respondidas (minhas tags) . Então eu acho que devo responder isso :)
APOIO DA AOSP AOS CAPACIDADES:
A pergunta é especificamente sobre dispositivos do Google, nunca usei um dispositivo do Google. No entanto, o que posso dizer com certeza é que os recursos do Linux (processo) devem ter sido ativados na maioria dos dispositivos (se não todos) rodando tão baixo quanto o Android 1.6. A referência é encontrada em inite system_server, ambos os componentes principais do AOSP. No Android 4.2, por exemplo, installd- outro componente principal - foi criado para rodar com recursos descartados.
Os recursos do sistema de arquivos foram um dos principais aprimoramentos de segurança no Android 4.3, que removeram set-uid/ set-giddos binários run-as, definindo os recursos de arquivo neles. Isso causou mudanças revolucionárias na jornada de root do Android.
O suporte aos recursos Ambient foi adicionado no Android 8, o que desencoraja o uso dos recursos de arquivo:
Os recursos de arquivo, por sua vez, apresentam um risco de segurança, pois qualquer processo que execute um arquivo com recursos de arquivo poderá obter esses recursos.
Muitos initserviços dependem deles storaged, por exemplo , incluindo os meus sshde dnscrypt-proxyserviços.
SUPORTE DE KERNEL PARA CAPACIDADES:
Chegando à parte do kernel, construir o kernel sem recursos não é opcional:
Do kernel 2.5.27 ao 2.6.26, os recursos eram um componente opcional do kernel e podiam ser ativados / desativados através da opção de configuração do kernel CONFIG_SECURITY_CAPABILITIES .
E:
Nos kernels anteriores ao Linux 2.6.33, os recursos do arquivo eram um recurso opcional configurável através da opção CONFIG_SECURITY_FILE_CAPABILITIES . Desde o Linux 2.6.33, a opção de configuração foi removida e os recursos de arquivo sempre fazem parte do kernel.
A versão mais antiga do kernel comum nos repositórios do Android é a 2.6.39, que também inclui suporte para recursos de arquivo.
O suporte para recursos do sistema de arquivos no lado do kernel deve ter sido atrasado por alguns OEMs, mas eles tiveram que mudar, porque, caso contrário, as funcionalidades quebrariam. Por exemplo, surfaceflingero compositor de superfície do Android não funcionará sem os recursos de arquivo desde o Android 7.1.
O kernel principal do Linux 4.3 foi corrigido em Sep'15 para os recursos Ambient (processo), portado para o kernel do Android 3.18 e 4.1 em 2016. Portanto, eles são necessariamente parte do kernel.
CONCLUSÃO:
Nas distribuições Linux, poucos programas utilizam os recursos do Linux. Embora não haja pam_cap, em sua maioria (ou todos?) Distros ainda usam set-uidem su, sudo, ping, mount, passwde assim por diante. Porém, no Android, os recursos estão profundamente integrados na estrutura e nos serviços principais. Removê-los exigiria a edição de centenas ou pode haver milhares de linhas no AOSP e na fonte do kernel. Não faz sentido que um OEM (particularmente o Google, que desenvolveu o AOSP e o kernel do Linux modificado para Android) não faça uso desse recurso de segurança gratuito quando estiver prontamente disponível no kernel do Android. É um recurso puro relacionado ao sistema operacional, não exige nenhum suporte extra de hardware. Portanto, qualquer telefone de qualquer fabricante deve ter recursos suportados.
QUESTÕES:
eu seria capaz de definir recursos em executáveis sem alterar o binário original do kernel?
Sim, você deve ser.
As coisas necessárias são ferramentas para definir limites ...
Tenho vindo a utilizar capsh, getcap, setcap, getpcapsa partir libcape netcap, pscapa partir libcap-ngsem quaisquer problemas. Mas eu prefiro os recursos Ambient, são fáceis de configurar e não dependem de nenhum recurso do sistema de arquivos, como Atributos Estendidos, como no caso dos recursos do arquivo. Você também pode usar listxattr, getxattr, setxattre removexattrferramentas de xattr_syscall_wrappermanipular security.capabilityou de qualquer outra xattr diretamente.
Do seu comentário:
Acabei de notar que o /system/bin/pingcomando não está setuidno meu dispositivo Samsung real, sugerindoCAP_NET_RAW
O ping do Android não tem set-uidnem CAP_NET_RAW. Ele cria um soquete não-RAW especial IPPROTO_ICMPque - ao contrário IPPROTO_RAW- não requer privilégios.
REFERÊNCIAS ADICIONAIS:
Além das mais de 10 referências fornecidas acima, aqui estão algumas outras partes do código AOSP que suportam e fazem uso dos recursos do Linux:
- Componentes principais: Bionic
libc, init, trusty(OS)
- Componentes externos:
libcap ,libcap-ng
- Daemons / serviços:
zygote (aplicativos bifurcada e system_server), hostapd, wpa_supplicant, dnsmasq, logd, netd( NetLinkgerente, DNS privado), debuggerd(teste), sdcarddaemon, performanced, incidentd, mtpd, traced_probes(perfetto), racoon(IPSec), wificond, um número de daemons HAL inclusive rild.
- Executáveis:
reboot (INIT), dumpstate, tcpdump, strace, iputils( ping, tracerouteetc.)
- Minijail: uma ferramenta e uma biblioteca dedicadas para sandbox que gira em torno de recursos.
adbdfaz uso dessa biblioteca para eliminar privilégios.
- O SELinux usa a
capabilityclasse para conceder / negar recursos aos domínios.
Conclui que o Android depende muito dos recursos do Linux, não é um recurso pouco usado .
RELACIONADOS: