Aunque la pregunta es antigua, sigue apareciendo en la parte superior de Sin respuesta (mis etiquetas) preguntas. Así que creo que debo responder a esto :)
APOYO DE AOSP A LAS CAPACIDADES:
La pregunta es específicamente sobre los dispositivos de Google, nunca he utilizado un dispositivo de Google. Sin embargo, lo que puedo decir con certeza es que las capacidades de Linux (proceso) debe haber sido habilitado en la mayoría de los dispositivos (si no todos) que se ejecuta tan bajo como Android 1.6. La referencia se encuentra en init y system_server , ambos componentes muy primarios de la AOSP. En Android 4.2, por ejemplo, installd - otro componente principal- se hizo para funcionar con capacidades caídas.
Capacidades del sistema de archivos fueron uno de los principales Mejoras de seguridad en Android 4.3 que eliminó set-uid / set-gid de binarios como run-as , estableciendo las capacidades de los archivos en ellos. Esto causó cambios revolucionarios en el viaje del rooting de Android.
Apoyo a Capacidades ambientales se añadió en Android 8 que desaconseja el uso de las capacidades de los archivos:
Las capacidades de los archivos, a su vez, presentan un riesgo de seguridad ya que cualquier proceso que ejecute un archivo con capacidades de archivo podrá obtener dichas capacidades.
Muchos init los servicios dependen de ellos, por ejemplo storaged incluyendo el mío propio sshd y dnscrypt-proxy servicios.
SOPORTE DEL KERNEL PARA LAS CAPACIDADES:
Llegando a la parte del kernel, construir el kernel sin capacidades no es opcional:
Desde el núcleo 2.5.27 hasta el 2.6.26, las capacidades eran un componente opcional del núcleo, y podían activarse/desactivarse mediante la opción CONFIG_SECURITY_CAPABILITIES opción de configuración del kernel.
Y:
En los núcleos anteriores a Linux 2.6.33, las capacidades de los archivos eran una característica opcional configurable a través de la función CONFIG_SECURITY_FILE_CAPABILITIES opción. Desde Linux 2.6.33, la opción de configuración ha sido eliminada y las capacidades de los archivos son siempre parte del núcleo.
La versión más antigua del núcleo común en los repositorios de Android es la 2.6.39 que incluye también soporte para las capacidades de los archivos.
El soporte para las capacidades del sistema de archivos en el lado del kernel debe haber sido retrasado de algunos OEM, pero tuvieron que cambiar, porque de lo contrario se romperían las funcionalidades. Por ejemplo surfaceflinger (Android's compositor de superficies ) no funcionará sin las capacidades de los archivos desde Android 7.1.
El núcleo principal de Linux 4.3 fue parcheado en septiembre de 15 para las capacidades de Ambient (proceso), con respaldo al kernel de Android 3.18 y 4.1 en 2016. Así que son necesariamente una parte del kernel.
CONCLUSIÓN:
En las distribuciones de Linux, un muy pocos programas hacen uso de las capacidades de Linux. Aunque hay pam_cap la mayoría (¿o todas?) de las distros siguen utilizando set-uid en su , sudo , ping , mount , passwd y así sucesivamente. Pero en Android las capacidades están profundamente integradas en el marco y los servicios centrales. Eliminarlas requeriría editar cientos o quizás miles de líneas en el código fuente de AOSP y del kernel. No tiene sentido que un OEM (particularmente Google, que desarrolló AOSP y modificó el kernel de Linux para Android) no haga uso de esto gratis función de seguridad cuando está disponible en el núcleo de Android. Es una característica puramente relacionada con el sistema operativo, no requiere ningún soporte de hardware adicional. Así que cualquier teléfono de cualquier fabricante debe tener capacidades soportadas.
PREGUNTAS:
¿podría establecer capacidades en los ejecutables sin cambiar el binario original del kernel?
Sí, debes estarlo.
Lo que se necesita son herramientas para poner tapas...
He estado usando capsh , getcap , setcap , getpcaps de libcap y netcap , pscap de libcap-ng sin ningún problema. Pero prefiero las capacidades de Ambient, que son fáciles de configurar y no dependen de ninguna característica del sistema de archivos como Atributos ampliados como en el caso de las capacidades de los archivos. También puede utilizar listxattr , getxattr , setxattr y removexattr herramientas de xattr_syscall_wrapper para manipular security.capability o cualquier otro XATTR directamente.
De su comentario:
Acabo de darme cuenta de que el /system/bin/ping comando no es setuid en mi dispositivo Samsung real, sugiriendo CAP_NET_RAW
Android's ping tampoco tiene set-uid ni CAP_NET_RAW . Crea una no RAT toma de corriente IPPROTO_ICMP que, a diferencia de IPPROTO_RAW - no requiere ningún privilegio.
OTRAS REFERENCIAS:
Además de las más de 10 referencias mencionadas anteriormente, aquí hay otras partes del código de AOSP que soportan y hacen uso de las capacidades de Linux:
- Componentes básicos: Bionic
libc , init , trusty (OS)
- Componentes externos:
libcap , libcap-ng
- Daemons / servicios:
zygote (aplicaciones bifurcadas y system_server ), hostapd , wpa_supplicant , dnsmasq , logd , netd ( NetLink gestor, DNS privado), debuggerd (prueba), sdcard demonio, performanced , incidentd , mtpd , traced_probes (perfetto), racoon (IPSec), wificond una serie de demonios de HAL, entre ellos rild .
- Ejecutables:
reboot (init), dumpstate , tcpdump , strace , iputils ( ping , traceroute etc.)
- Minijail: Una herramienta y una biblioteca dedicadas al sandboxing que giran en torno a las capacidades.
adbd hace uso de esta biblioteca para dejar los privilegios.
- SELinux utiliza
capability para conceder / denegar capacidades a los dominios.
Concluye que Android depende en gran medida de las capacidades de Linux, no es un poco usado característica.
RELACIONADO:
2 votos
Tampoco pude encontrar un emulador de nexus
0 votos
Lo dudo... Dado que Android utiliza Bionic libc y no la librería estándar GNU libc (glibc), no es ni de lejos compatible con POSIX. Tal vez puedas compilar tu propio kernel con una libc diferente como CrystaX NDK en lugar de Bionic, pero no sé si esas características están en eso tampoco.
0 votos
@acejavelin : la parte de userland sólo es necesaria para establecer atributos extendidos que contengan capacidades. Todo lo demás es del lado del kernel. Acabo de notar que el
/system/bin/pingel comando no es setuid en mi dispositivo samsung real, lo que sugiereCAP_NET_RAW. Sin embargo, no voy a Root un dispositivo real y no sé qué herramienta puedo utilizar para ver las informaciones pertinentes, así que no puedo comprobar.0 votos
¿Por qué no rootearías un dispositivo Nexus? Está pensado para eso y no anula su garantía. Es muy sencillo restaurar cualquier dispositivo Nexus a su estado predeterminado, sin root y bloqueado, el dispositivo es básicamente unbrickable.
0 votos
@acejavelin : No tengo un dispositivo nexus Mi objetivo es la investigación de seguridad y google sólo recompensa por sus propios dispositivos. Así que necesito saber si el kernel de uno de los dispositivos en mi pregunta apoyo utilizando capacidades xattr. Lo que estoy viendo en mi galaxy tab es probablemente solo relacionado con samsung. Si no incluyo el rooting en mi pregunta podría cerrarse por poco claro .
0 votos
Vale, por la redacción de tu pregunta pensaba que tenías uno pero quería saber si también funcionaba en el resto de modelos de Nexus. Entendí mal que se trataba de una pregunta hipotética o de investigación.
0 votos
@acejavelin : He escrito
The problem of course is I don’t own such device.En mi pregunta.