4 votes

Comment puis-je définir la bonne politique SELinux / SEAndroid pour une application ?

J'utilise l'application gratuite SSHelper Serveur SSH sur mon téléphone pour obtenir un accès SSH. Cependant, l'application ne se comporte pas correctement dans les cas suivants SELinux lorsqu'il est réglé sur Enforcing mais semblent fonctionner correctement en utilisant le mode Permissive mode. Ce n'est pas surprenant car il a été développé sous CyanogenMod L'auteur n'est donc pas au courant de ces problèmes pour les AOS de stock appliquant SELinux.

Le problème se produit lorsque l'application tente d'allouer un /dev/pts/N pseudo-terminal, pendant la connexion SSH. Cela échoue et le shell résultant est essentiellement inutile pour le développement. Après avoir passé un temps considérable à essayer de retrouver ce problème comme documenté ICI . Où j'ai trouvé les "erreurs" suivantes dans l'application /data/misc/audit/audit.log fichier :

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

Cependant, comme je n'ai aucune expérience préalable de SELinux et de ses mystérieux mécanismes de protection, j'aurais vraiment besoin d'aide. Je ne sais même pas si c'est le vrai problème, juste une supposition. La vérification des permissions du fichier ci-dessus donne :

# 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

Mais cette context ne semble pas du tout correspondre à ce qui a été montré dans la journal .

Comment puis-je fixer ces permissions pour qu'elles fonctionnent bien avec SELinux lorsqu'en Mise en application de mode ?

(Par ailleurs, quels sont les outils et les fichiers disponibles dans Android pour résoudre ce problème ?)

0 votes

S'agit-il de développer l'application ou de configurer l'appareil ?

0 votes

Configurer l'appareil et "réparer" l'application, puisque l'application est déjà développée, mais je n'ai pas réussi à contacter le développeur. J'ai également essayé d'autres applications similaires avec exactement les mêmes problèmes. Il semble que la plupart des développeurs d'applications n'ont pas encore appris à connaître et à comprendre comment configurer et utiliser correctement ces mystérieuses et très ennuyeuses fonctionnalités SELinux.

2voto

Priyank Bolia Points 3825

Je pense que le problème pourrait être le "domaine non confiné" par défaut que le binaire exécute lorsqu'aucune politique n'est spécifiée.

Une tentative que j'essaierais serait de déplacer les sshelper_sshd (je pense que c'est le serveur sshd ?) quelque part sur le /system partition ( /system/sbin/ ?)

Je pense que le meilleur document à lire, et le plus à jour, pour traiter de l'implémentation de SELinux sur Android (SEAndroid) est le suivant How-To SU .

Voici un extrait du chapitre 5.4.4. Android 4.4.3

Un bon exemple du fait que le domaine non confiné n'est pas tout-puissant est l'exécution de fichiers depuis /data. À partir d'Android 4.4.3, cela ne sera plus possible à partir du domaine non confiné (voir #74082 et #78801).

La pratique établie consistant à inclure des binaires et des scripts dans votre APK, à les extraire dans /data/data/[package]/files/ ou à les placer dans /data/data/[package]/lib/ et à les exécuter à partir de là par un appel su ne fonctionnera plus. Bien qu'il existe d'autres solutions de contournement (comme la copie et l'exécution à partir de rootfs), une solution consiste à basculer les contextes vers un contexte qui n'est pas dans le domaine non confiné (comme u:r:untrusted_app:s0, le contexte sous lequel le reste de votre application est susceptible de s'exécuter). Vous devrez cependant effectuer des tests approfondis pour vérifier que tous les appels que vous souhaitez effectuer s'exécutent toujours dans le contexte choisi, et vous devrez peut-être en essayer d'autres pour obtenir les capacités que vous souhaitez.

Notez que l'exécution des fichiers dans /data fonctionnera toujours comme prévu à partir de votre application si vous n'essayez pas de l'exécuter en tant que Root.

0 votes

Oui, j'ai lu tout cela plusieurs fois, mais je ne sais toujours pas quelle action exacte entreprendre. J'ai essayé de chconer le binaire avant avec des résultats qui ne fonctionnent pas. Peut-être en liant le binaire dans /xbin, mais alors comment puis-je m'assurer que l'application utilise cela au lieu de l'original ? De plus, quel devrait être le contexte ? Comment puis-je savoir quel contexte est (ou n'est pas) dans le "domaine non confiné" ?

0 votes

Je dois ajouter que je suis pas le développeur de cette application, donc je n'ai aucun moyen de la changer. Je ne peux modifier l'emplacement et le contexte des fichiers concernés qu'à partir de la ligne de commande, une fois l'application installée.

androidalle.com

AndroidAlle est une communauté de androiders où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X