Comment invoquer «su» à partir d'une invite de terminal?

7

Je peux obtenir une invite racine dans le terminal en exécutant un exploit documenté ailleurs. (par exemple ici: http://wiki.cyanogenmod.com/wiki/Motorola_Droid_2_Global:_Full_Update_Guide )

À ce stade, je peux installer le binaire "su" et lui donner les autorisations 4755. Cela devrait permettre à quiconque de l'exécuter, et puisque le propriétaire du binaire est "root" et que le bit collant est défini, je devrais devenir root. Mais je n'ai apparemment aucun moyen de ne pas devenir root à partir du terminal avant de redémarrer. Mais, après avoir redémarré, je n'arrive pas à devenir root en utilisant 'su'.

$ ls -l /system/bin/su
-rwsr-xr-x root    app_101    26234 2012-07-09 15:00 su

D'accord, les autorisations semblent bonnes, si je devais pouvoir l'exécuter pour devenir root, mais uniquement dans cette invocation particulière du terminal.

$ /system/bin/su
Permission denied

Il échoue également si je spécifie la commande à exécuter en tant que root, ou avec tout autre argument:

$ /system/bin/su /system/bin/sh
Permission denied

Pourquoi? Y a-t-il un autre mécanisme à l'œuvre? Je ne veux pas installer Superuser.apk, car je veux juste un moyen d'obtenir temporairement un shell racine si nécessaire, par exemple pour supprimer manuellement les fichiers indésirables. De plus, Superuser.apk s'appuie de toute façon sur le binaire su, donc il doit avoir un moyen de l'appeler, alors pourquoi ne puis-je pas le répliquer dans le terminal?

Edit: J'ai eu une autre pensée, j'ai donc essayé de copier / bin / sh vers un autre emplacement et en faire une racine suid. Mais bien que je puisse exécuter le nouveau binaire, il ne me donne pas de racine. Android fait-il quelque chose de délicat / différent avec suid que Linux ordinaire ne fait pas?

Michael
la source
1
Avoir un `` su '' non protégé sur l'appareil est assez risqué, car tout ce qui tente de l'utiliser l'obtiendra sans aucune confirmation de l'utilisateur que des choses comme cette application de superutilisateur essaient d'ajouter comme passerelle.
Chris Stratton
Bon, eh bien ... j'essayais de planifier à l'avance. Je ne savais pas comment une mise à jour ultérieure essaierait de se débarrasser de su, alors je l'ai mis dans un tas d'endroits différents avec des noms différents. Il s'avère que la mise à jour supprime le bit collant, et je ne peux pas exécuter suid ailleurs que sur le système. Et bien.
Michael

Réponses:

6

L'indice est dans l'ID du propriétaire / groupe ...

$ ls -l /system/bin/su
-rwsr-xr-x root    app_101    26234 2012-07-09 15:00 su

Notez que l'ID de groupe est défini sur 'app_101', qui devrait être 'root', mais là encore, vous avez besoin du busyboxbinaire (qui fait partie du binaire SuperUser.apk, une fois installé, il copie ledit binaire pertinent /system/xbin) dans l'ordre pour pouvoir le faire chown.

t0mm13b
la source
Oui, ce serait un problème En fin de compte, la boîte occupée n'est pas nécessaire car le chown Android stock peut également changer le groupe, en utilisant le nom de fichier chown user.group (au moins de Froyo-ICS)
Chris Stratton
1

Essayez d'ajouter l' -coption. par exemple

su -c sh

ou

 su -c 'echo bogus'

(pour plus d'arguments)

d14b0ll0s
la source
0

Un peu plus de fouilles et je pense avoir trouvé la réponse. La raison pour laquelle cela ne fonctionne pas est que l'application Terminal ne demande pas l'autorisation de super-utilisateur dans son manifeste, par exemple:

<uses-permission android:name="android.permission.ACCESS_SUPERUSER"/>

Cette couche de sécurité supplémentaire semble être due au fait que l'application de terminal est une application java, bien qu'elle le masque bien. Le superutilisateur semble caler les choses de manière à ce que les applications java puissent obtenir cette autorisation, même si elles ne savaient pas qu'elles en avaient besoin lors de leur création.

Michael
la source
2
ACCESS_SUPERUSERl'autorisation n'est pas liée à votre problème
janot