Aunque la pregunta es antigua, sigue apareciendo sobre las preguntas sin respuesta (mis etiquetas) . Así que creo que debería responder esto :)
APOYO DE AOSP A LAS CAPACIDADES:
La pregunta es específicamente sobre los dispositivos de Google, nunca he usado un dispositivo de Google. Sin embargo, lo que puedo decir con certeza es que las capacidades de Linux (proceso) deben haberse habilitado en la mayoría de los dispositivos (si no todos) que se ejecutan tan bajo como Android 1.6. Se encuentra referencia en init
y system_server
, ambos componentes muy primarios de AOSP. En Android 4.2, por ejemplo, installd
otro componente central, se hizo funcionar con capacidades caídas.
Las capacidades del sistema de archivos fueron una de las principales mejoras de seguridad en Android 4.3 que eliminaron set-uid
/ set-gid
de los archivos binarios run-as
, como configurar las capacidades de los archivos en ellos. Esto causó cambios revolucionarios en el viaje de rooteo de Android.
Se agregó soporte para capacidades ambientales en Android 8, lo que desalienta el uso de capacidades de archivo:
Las capacidades de archivo, a su vez, presentan un riesgo de seguridad ya que cualquier proceso que ejecute un archivo con capacidades de archivo podrá obtener esas capacidades.
Muchos init
servicios dependen de ellos storaged
, por ejemplo , incluido el mío sshd
y los dnscrypt-proxy
servicios.
APOYO DE KERNEL A LAS CAPACIDADES:
Llegando a la parte del kernel, construir kernel sin capacidades no es opcional:
Desde el kernel 2.5.27 hasta el kernel 2.6.26, las capacidades eran un componente opcional del kernel y se podían habilitar / deshabilitar a través de la opción de configuración del kernel CONFIG_SECURITY_CAPABILITIES .
Y:
En los núcleos anteriores a Linux 2.6.33, las capacidades de archivo eran una característica opcional configurable a través de la opción CONFIG_SECURITY_FILE_CAPABILITIES . Desde Linux 2.6.33, la opción de configuración se ha eliminado y las capacidades de archivo siempre forman parte del núcleo.
La versión de kernel común más antigua en los repositorios de Android es 2.6.39, que también incluye soporte para capacidades de archivo.
El soporte para las capacidades del sistema de archivos en el lado del kernel debe haberse retrasado por parte de algunos OEM pero tuvieron que cambiar, porque de lo contrario las funcionalidades se romperían. Por ejemplo surfaceflinger
(el compositor de superficie de Android ) no funcionará sin capacidades de archivo desde Android 7.1.
Mainline Linux kernel 4.3 fue parcheado en Sep'15 para capacidades Ambient (proceso), retroportado a Android kernel 3.18 y 4.1 en 2016. Por lo tanto, son necesariamente una parte del kernel.
CONCLUSIÓN:
En las distribuciones de Linux, muy pocos programas hacen uso de las capacidades de Linux. Aunque no es pam_cap
, en su mayoría (o todos)? Distribuciones siguen utilizando set-uid
en su
, sudo
, ping
, mount
, passwd
y así sucesivamente. Pero las capacidades de Android están profundamente integradas en el marco y los servicios básicos. Eliminarlos requeriría editar cientos o pueden ser miles de líneas en AOSP y en la fuente del núcleo. No tiene sentido que un OEM (especialmente Google, que desarrolló y modificó AOSP núcleo de Linux para Android) no hace uso de esta libre de costo característica de seguridad cuando está fácilmente disponible en Android kernel. Es una característica pura relacionada con el sistema operativo, no requiere ningún soporte de hardware adicional. Por lo tanto, cualquier teléfono de cualquier fabricante debe tener capacidades compatibles.
PREGUNTAS
¿Sería capaz de establecer capacidades en ejecutables sin cambiar el binario original del núcleo?
Sí, debes serlo.
Las cosas requeridas son herramientas para establecer tapas ...
He estado usando capsh
, getcap
, setcap
, getpcaps
de libcap
y netcap
, pscap
a partir libcap-ng
sin ningún problema. Pero prefiero las capacidades ambientales, que son fáciles de configurar y no dependen de ninguna función del sistema de archivos, como los atributos extendidos, como en el caso de las capacidades de archivo. También se puede utilizar listxattr
, getxattr
, setxattr
y removexattr
herramientas de xattr_syscall_wrapper
manipular security.capability
o de cualquier otra xattr directamente.
De tu comentario:
Acabo de notar que el /system/bin/ping
comando no está setuid
en mi dispositivo Samsung real, lo que sugiereCAP_NET_RAW
El ping de Android no tiene set-uid
ni CAP_NET_RAW
. Crea un socket especial no RAWIPPROTO_ICMP
que, a diferencia de IPPROTO_RAW
, no requiere ningún privilegio.
MÁS REFERENCIAS:
Además de más de 10 referencias dadas anteriormente, aquí hay algunas otras partes del código AOSP que admiten y hacen uso de las capacidades de Linux:
- Los componentes básicos: Bionic
libc
, init
, trusty
(SO)
- Los componentes externos:
libcap
,libcap-ng
- Demonios / servicios:
zygote
(aplicaciones bifurcadas y system_server
), hostapd
, wpa_supplicant
, dnsmasq
, logd
, netd
( NetLink
gerente, DNS privada), debuggerd
(prueba), sdcard
demonio, performanced
, incidentd
, mtpd
, traced_probes
(perfetto), racoon
(IPSec), wificond
un número de demonios HAL incluidos rild
.
- Ejecutables:
reboot
(init), dumpstate
, tcpdump
, strace
, iputils
( ping
, traceroute
etc.)
- Minijail: una herramienta y biblioteca de sandboxing dedicada que gira en torno a las capacidades.
adbd
hace uso de esta biblioteca para eliminar privilegios.
- SELinux usa la
capability
clase para otorgar / negar capacidades a los dominios.
Concluye que Android depende en gran medida de las capacidades de Linux, no es una característica poco utilizada .
RELACIONADO: