Estoy usando el SSHelperservidor SSH gratuito en mi teléfono para obtener acceso SSH. Sin embargo, la aplicación no se comporta correctamente SELinuxcuando está configurada en el Enforcingmodo, pero parece estar bien cuando se usa el Permissivemodo. Esto no es sorprendente, ya que fue desarrollado bajo CyanogenMod , lo que hace que el autor desconozca estos problemas para posteriores AOS de stock de SELinux Enforcing.
El problema ocurre cuando la aplicación intenta asignar una /dev/pts/Npseudo-terminal, durante la conexión SSH. Esto falla y el shell resultante es esencialmente inútil para el desarrollo. Después de haber pasado un tiempo considerable tratando de rastrear este problema como se documenta AQUÍ . Donde encontré los siguientes "errores" en el /data/misc/audit/audit.logarchivo:
audit(1401291488.480:203): avc: denied { setattr } for pid=11441 comm="sshelper_sshd" name="0" dev="devpts" ino=3 scontext=u:r:untrusted_app:s0 tcontext=u:object_r:untrusted_app_devpts:s0 tclass=chr_file VE=SEPF_GT-I9195_4.2.2_0022_M
audit(1401291488.480:203): arch=40000028 syscall=15 per=840000 success=no exit=-13 a0=beffd438 a1=190 a2=27da a3=c0000000 items=1 ppid=8499 pid=11441 auid=4294967295 uid=10202 gid=10202 euid=10202 suid=10202 fsuid=10202 egid=10202 sgid=10202 fsgid=10202 tty=(none) ses=4294967295 comm="sshelper_sshd" exe="/data/data/com.arachnoid.sshelper/bin/sshelper_sshd" subj=u:r:untrusted_app:s0 key=(null)
audit(1401291488.480:203): cwd="/"
audit(1401291488.480:203): item=0 name="/dev/pts/0" inode=3 dev=00:09 mode=020600 ouid=10202 ogid=10202 rdev=88:00 obj=u:object_r:untrusted_app_devpts:s0
Sin embargo, dado que no tengo experiencia previa en SELinux y sus misteriosos mecanismos de protección, realmente me vendría bien un poco de ayuda. Ni siquiera sé si este es el problema real, solo supuse. Verificar los permisos del archivo anterior da:
# ls -alZ /data/data/com.arachnoid.sshelper/bin/sshelper_sshd
-rwxr-xr-x u0_a202 u0_a202 u:object_r:app_data_file:s0 sshelper_sshd
Pero esto contextno parece corresponder en absoluto a lo que se muestra en el registro .
¿Cómo puedo arreglar estos permisos para jugar bien con SELinux cuando estoy en el modo Ejecución ?
(Además, ¿qué herramientas y archivos están disponibles en Android para solucionar esto?)
Creo que el problema podría ser el "dominio no confinado" predeterminado, el binario se ejecuta cuando no se especifica ninguna política.
Un intento que intentaría sería mover el sshelper_sshd(¿creo que es el servidor sshd?) En algún lugar de la /systempartición ( /system/sbin/?)
Creo que el mejor y más actualizado documento para leer sobre la implementación de SELinux en Android (SEAndroid) es How-To SU .
Aquí un extracto del Capítulo 5.4.4. androide 4.4.3
Un buen ejemplo de que el dominio no confinado no es todopoderoso es ejecutar archivos desde /data. A partir de Android 4.4.3, esto ya no será posible desde el dominio no confinado (ver #74082 y #78801).
La práctica establecida de incluir archivos binarios y scripts en su APK, extraerlos a /data/data/[paquete]/files/ o colocarlos en /data/data/[paquete]/lib/ y ejecutarlos desde allí a través de una llamada su ya no funcionará fuera de la caja. Si bien existen otras soluciones posibles (como copiar y ejecutar desde rootfs), una solución es cambiar los contextos a un contexto que no esté en el dominio no confinado (como u:r:untrusted_app:s0, es probable que el contexto del resto de su aplicación para ejecutar como). Sin embargo, deberá realizar pruebas exhaustivas para ver si todas las llamadas que desea realizar aún se ejecutan en el contexto que elija, y es posible que deba probar algunas diferentes para obtener las capacidades que desea.
Tenga en cuenta que la ejecución de archivos en /data seguirá funcionando como se espera de su aplicación si no está intentando ejecutarla como root.
Vi0
no2qubit