¿Hay dispositivos de Google que admitan capacidades en su núcleo predeterminado?

Si rooteo sin sistema (no se realizó ninguna modificación en la /systempartición) de un dispositivo Nexus, ¿podría establecer capacidades en ejecutables sin cambiar el binario original del núcleo?

A menudo quiero administrar archivos sin restricciones desde mi terminal (requiere CAP_DAC_READ_SEARCH) . Sin embargo, tampoco quiero usar el superusuario.
Las cosas requeridas son herramientas para establecer límites a lo largo del soporte del kernel para usarlas (no depende de otras cosas del espacio del usuario) .

El problema es que no tengo ese dispositivo. Así que no puedo decir si funcionaría en alguno de ellos Nexus 5X Nexus 6P Nexus 9 Pixel C.

— usuario2284570
fuente

Tampoco pude encontrar un emulador nexus ...

— user2284570

Lo dudo ... Dado que Android usa Bionic libc y no la biblioteca estándar GNU libc (glibc), ni siquiera es compatible con POSIX. Es posible que pueda compilar su propio kernel con una biblioteca diferente como CrystaX NDK en lugar de Bionic, pero tampoco sé si esas características están en eso.

— acejavelin

@acejavelin: la parte del usuario solo es necesaria para establecer atributos extendidos que contengan capacidades. Todo lo demás está del lado del kernel. Acabo de notar que el /system/bin/pingcomando no está configurado en mi dispositivo Samsung real, lo que sugiere CAP_NET_RAW. Sin embargo, no rootearé un dispositivo real y no sé qué herramienta puedo usar para ver la información relevante, por lo que no puedo verificarlo.

— user2284570

¿Por qué no rootearías un dispositivo Nexus? Está destinado a eso y no anula su garantía. Es muy simple restaurar cualquier dispositivo Nexus a su estado predeterminado, desrooteado y bloqueado, el dispositivo es básicamente indestructible.

— acejavelin

@acejavelin: no soy dueño de un dispositivo nexus ... Mi objetivo es la investigación de seguridad y Google solo recompensa por sus propios dispositivos. Entonces, necesito saber si el núcleo de uno de los dispositivos en mi pregunta admite el uso de capacidades xattr. Lo que estoy viendo en mi pestaña galaxia probablemente solo esté relacionado con Samsung. Si no involucro el enraizamiento en mi pregunta, podría cerrarse como poco claro .

— user2284570

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 inity system_server, ambos componentes muy primarios de AOSP. En Android 4.2, por ejemplo, installdotro 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-gidde 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 initservicios dependen de ellos storaged, por ejemplo , incluido el mío sshdy los dnscrypt-proxyservicios.

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 .

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-uiden su, sudo, ping, mount, passwdy 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, getpcapsde libcapy netcap, pscapa partir libcap-ngsin 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, setxattry removexattrherramientas de xattr_syscall_wrappermanipular security.capabilityo de cualquier otra xattr directamente.

De tu comentario:

Acabo de notar que el /system/bin/pingcomando no está setuiden mi dispositivo Samsung real, lo que sugiereCAP_NET_RAW

El ping de Android no tiene set-uidni CAP_NET_RAW. Crea un socket especial no RAW IPPROTO_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( NetLinkgerente, DNS privada), debuggerd(prueba), sdcarddemonio, performanced, incidentd, mtpd, traced_probes(perfetto), racoon(IPSec), wificondun número de demonios HAL incluidos rild.
Ejecutables: reboot (init), dumpstate, tcpdump, strace, iputils( ping, tracerouteetc.)
Minijail: una herramienta y biblioteca de sandboxing dedicada que gira en torno a las capacidades. adbdhace uso de esta biblioteca para eliminar privilegios.
SELinux usa la capabilityclase 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:

— Irfan Latif
fuente

No responde nada en absoluto. Todo lo que dijiste es conocido. El punto de la pregunta es que se usa poco si los dispositivos de la marca Google lo incluyen.

— user2284570