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 init
e 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-gid
dos 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 init
serviços dependem deles storaged
, por exemplo , incluindo os meus sshd
e dnscrypt-proxy
serviç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, surfaceflinger
o 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-uid
em su
, sudo
, ping
, mount
, passwd
e 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
, getpcaps
a partir libcap
e netcap
, pscap
a partir libcap-ng
sem 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
, setxattr
e removexattr
ferramentas de xattr_syscall_wrapper
manipular security.capability
ou de qualquer outra xattr diretamente.
Do seu comentário:
Acabei de notar que o /system/bin/ping
comando não está setuid
no meu dispositivo Samsung real, sugerindoCAP_NET_RAW
O ping do Android não tem set-uid
nem CAP_NET_RAW
. Ele cria um soquete não-RAW especial IPPROTO_ICMP
que - 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
( NetLink
gerente, DNS privado), debuggerd
(teste), sdcard
daemon, 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
, traceroute
etc.)
- Minijail: uma ferramenta e uma biblioteca dedicadas para sandbox que gira em torno de recursos.
adbd
faz uso dessa biblioteca para eliminar privilégios.
- O SELinux usa a
capability
classe para conceder / negar recursos aos domínios.
Conclui que o Android depende muito dos recursos do Linux, não é um recurso pouco usado .
RELACIONADOS: