Frage:
Welche besonderen Berechtigungen "/ system / xbin / su" hat w.r.t. Root-Zugriff?
Oren Milman
2019-02-10 14:49:32 UTC
view on stackexchange narkive permalink

Diese Antwort lautet:

Aufgrund der Konfiguration von Verzeichnis- / Dateiberechtigungen unter Android benötigen Sie den Code su binär auf Ihrer / system -Partition, damit es funktioniert. Das Platzieren an anderer Stelle reicht nicht aus, da es nicht über die erforderlichen Berechtigungen verfügt, damit Prozesse Benutzer wechseln können.

Welcher Mechanismus verursacht Binärdateien in / system um besondere Berechtigungen zu haben?
Insbesondere, wenn ich / system / xbin / su nach / data / xbin / su verschoben habe (und alles Relevante geändert habe, um darauf zu verweisen) / data / xbin / su anstelle von / system / xbin / su ), was wäre anders?



Ich vermute, dass diese Berechtigungen von SELinux erzwungen werden.
Ich habe die Quellen von Android durchsucht und in platform / system / sepolicy / private / file_contexts gefunden:

  /system(/.*)? u: object_r: system_file: s0  

und in platform / system / sepolicy / public / domain.te:

  erlauben {appdomain coredomain} system_file: file {read read get gettr map ausführen};  


Ich habe es jedoch auch in platform / system / sepolicy / private / file_contexts gefunden a>:

  / system / xbin / su u: object_r: su_exec: s0  

und in platform / system / sepolicy / public / domain.te:

  # Niemand sollte in der Lage sein, su für Benutzer-Builds auszuführen. # Bei userdebug / eng-Builds führen nur dumpstate, shell und # su selbst su.neverallow aus {domain userdebug_or_eng (`-dumpstate -shell -su ')} su_exec: Datei no_x_file_perms;  

Ich bin also verwirrt.

Einer antworten:
#1
+5
Irfan Latif
2019-02-16 19:28:07 UTC
view on stackexchange narkive permalink

Da Android auf dem Linux-Kernel basiert, funktionierte der Root-Zugriff durch Ausführen von / system / xbin / su - wie auf einem Linux-System - in guten alten Zeiten, aber nicht jetzt. Die Geschichte ist ein bisschen verdreht.

WAS IST SUID?
Das Besondere an / system / xbin / su ist nicht, dass es drin ist / system -Partition, aber das in dieser Binärdatei gesetzte set-user-ID-root (SUID) -Bit macht es zu etwas Besonderem. SUID ( S und Eigentümer U Ser ID bei Ausführung) ist eine spezielle Art von Berechtigung für den Linux-Kernel Erteilt dem neuen Prozess die Berechtigungen des Dateieigentümers, anstatt die Berechtigungen des übergeordneten Prozesses zu erben, der ihn ausführt. Da der Eigentümer von / system / xbin / su root (UID 0) ist, kann er die effektive UID des Prozesses bei der Ausführung auf 0 setzen, sodass der aufrufende Prozess Root-Zugriff hat.
Dies ist Teil der diskretionären Zugangskontrolle (DAC); Eine der Sicherheitsfunktionen des Linux-Kernels.

OBLIGATORY ACCESS CONTROL (MAC):
SELinux ist seit KitKat implementiert und kann steuern, wer ausführt su binär, indem Access Vector-Regeln definiert werden.

Beim userdebug / eng Build eines ROMs adb shell (durch Ausführen von su , wie Sie erwähnt haben) und adb daemon ( 1) kann Übergang durchführen ( 2, 3, 4, 5) sup>, um als Root mit uneingeschränktem Kontext u: r: su: s0 ( 6) sup> ausgeführt zu werden. adbd kann jedoch nicht als Root bei endgültigen Benutzer Builds ausgeführt werden ( 7, 8 sup>), weder su binär ist enthalten. Daher ist / system / xbin / su nur für Entwickler gedacht, die eng ineering- oder userdebug -Erstellungen eines ROM debuggen möchten, nicht für Endbenutzer ( 9) sup>. Und das zweite Besondere daran ist der SELinux-Kontext u: object_r: su_exec: s0 .

Weitere Informationen finden Sie unter Warum "adb root" nichts tut?.

WIE ANDROID EINGESCHRÄNKT WURZELT? Beim Erstellen eines ROM für Benutzer, der für Endbenutzer bestimmt ist, bietet das Platzieren von su unter / system selbst mit set-user-ID- keinen Vorteil. root . Eine normale App kann ihre Berechtigungen zum Rooten nicht durch Ausführen von su erhöhen, weil:

  • Beginnend mit Jelly Bean hat Android auf Dateifunktionen umgestellt (Eine Funktion ist eine Teilmenge der Root-Berechtigungen.) Anstatt sich auf Sicherheitslücken vom Typ set-user-ID zu verlassen. Ein sicherer Mechanismus: Umgebungsfunktionen wurde auch in Android Oreo eingeführt.
  • Systemdämonen und -dienste können Dateifunktionen verwenden, um Prozessfunktionen zu erhalten (siehe unter Transformation) von Funktionen während der Ausführung), aber Apps können dies auch nicht, da sie mit dem Prozesssteuerungsattribut NO_NEW_PRIVS ausgeführt werden und set-user-ID sowie ignorieren Dateifunktionen. SUID wird auch ignoriert, indem / system und / data ​​code> mit der Option nosuid für alle Apps bereitgestellt werden.
  • UID kann umgeschaltet werden Nur wenn der aufrufende Prozess die Fähigkeit SETUID / SETGID in seinem Begrenzungssatz hat (eine der 5 Fähigkeitskategorien, die ein Prozess haben kann). Android-Apps können jedoch mit allen Funktionen ausgeführt werden, die bereits in allen Sätzen verfügbar sind.
  • Ab Oreo wurde die Fähigkeit von Apps, UID / GID zu ändern, durch Blockieren bestimmter Systemaufrufe weiter unterdrückt Verwenden von seccomp-Filtern.
Der

ADB-Daemon wird jedoch mit CAP_SETUID und CAP_SETGID ausgeführt (um das Umschalten auf die UID / GID -Shell ??? zu ermöglichen). Aber auch die adb-Shell kann uns keine Funktionen bieten, indem sie eine SUID-root su -Binärdatei ausführt, da NOROOT und NO_SETUID_FIXUP Sicherheitsbits werden beim adbd -Prozess gesetzt. Im Gegensatz zu einem Debugging-Build werden keine Funktionen aus dem Begrenzungssatz ( 10) sup> entfernt, sodass / system / xbin / su (mit set-user-ID-root -Bit oder cap_setuid, cap_setgid + ep -Dateifunktionen) würden uns vollen Root-Zugriff verschaffen.

Syscalls, die in diesen Sandbox-Methoden verwendet werden: cap_set_proc , setresuid , setresgid , sys_seccomp , prctl (CAPBSET_DROP, SET_NO_NEW_PRIVS, SET_SECUREBITS , SET_SECCOMP) sind alle Teil von Minijail.


Zusammenfassend würden DAC und MAC nur adb root zulassen und / system / xbin / su von adb shell beim userdebug Build des ROM. Um Root-Zugriff von Apps und auf Benutzer Builds zu erhalten, die auf Endbenutzer ausgerichtet sind, müssen wir das Telefon rooten , wie unten erläutert.


WIE ERHALTEN SIE EINEN ROOT-ZUGRIFF AUF ANDROID?
Wenn wir also Berechtigungen mit UID 0 und allen 38 Funktionen des Linux-Kernels haben möchten, benötigen wir eine Root-Lösung, die damit umgehen kann mit allen oben beschriebenen Sicherheitsmaßnahmen. Da die eigenständigen su -Binärdateien mit der Veröffentlichung von Jelly Bean nicht mehr funktionieren, wurde in den su-Daemon-Modus gewechselt.

Auf einem gerooteten Telefon wird jetzt von Anfang an ein vollständig privilegierter Daemon ausgeführt (tatsächlich wird init ersetzt). Wenn eine App Root-Zugriff benötigt, führt sie su binär aus, die von der Root-Lösung bereitgestellt wird. Dieser su ändert die UID / GID nicht selbst, sondern stellt lediglich über einen UNIX-Socket eine Verbindung zum Superuser-Daemon her und fordert die anfordernde App auf, eine Root-Shell mit allen bereitzustellen Fähigkeiten. Um mit dem Benutzer zu interagieren, um su -Anforderungen von Apps zu erteilen / abzulehnen, ist der su-Daemon mit einer App verbunden, die Eingabeaufforderungen für die Benutzeroberfläche anzeigen kann. Eine Datenbank mit erteilten / verweigerten Berechtigungen wird von su daemon für die zukünftige Verwendung erstellt.
Darüber hinaus werden SELinux-Verweigerungen auch durch Definieren von SELinux-Richtlinien-Zulassungsregeln beim Rooten des Telefons behandelt.

Neue Methoden von root wie Magisk arbeiten im systemlosen Modus, dh ohne die / system -Partition zu ändern. Nur die Boot-Partition, die Kernel und initramfs enthält, wird geändert, um den su-Daemon-Dienst und neue SELiux-Richtlinien einzufügen. Ein gesperrter Bootloader startet keine modifizierte boot.img , daher muss der Bootloader entsperrt werden. Weitere Informationen hierzu finden Sie unter Entsperren des Bootloaders. Es gab jedoch einige Rooting-Hacks, bei denen die oben beschriebenen Sicherheitsimplementierungen umgangen wurden, ohne dass eine ordnungsgemäße Rooting-Methode gewählt wurde. Die meisten dieser Exploits und Schwachstellen in Android OS wurden im Laufe der Zeit behoben. Hier ist eine gute Beschreibung zu diesem Thema.

Abschließend platzieren Sie su binär unter / system oder einem anderen Ein anderer Standort bietet keine Vorteile.

Weitere Informationen finden Sie unter Funktionsweise von Magisk?.

PS: Bitte Ignorieren Sie so viele Links, dass sie für meine zukünftige Referenz dienen.

Gibt es eine Möglichkeit, Root-Zugriff in einer App auf einen user_debug-Build zu erhalten?Die Ausführung von `/ system / xbin / su` schlägt aufgrund von Selinux fehl, auch im zulässigen Modus!
@Paschalis nichts kann aufgrund von SELinux im zulässigen Modus fehlschlagen.Aber nicht nur SELinux führt dazu, dass `/ system / xbin / su` fehlschlägt.Die größeren Probleme sind das Attribut "NO_NEW_PRIVS" und die fehlgeschlagenen Funktionen für alle App-Prozesse.Deshalb brauchen wir einen Hintergrunddämon.Die Antwort auf Ihre Frage ist bereits vorhanden: * "Um Root-Zugriff von Apps zu erhalten ... müssen wir das Telefon ** rooten **" *.
TWRP ist für Android 10 nicht verfügbar, und beim Booten kann TWP / / system nicht gemountet werden.Und das Magisk-Patching von `boot.img` bricht ab, sobald ich etwas an` / system / lib64` und` / system / bin / `ändere.Ich frage mich, ob Sie etwas Zeit haben könnten, um dies in einem Chat zu besprechen.Danke vielmals!
@Paschalis Ich war bisher zu faul, um auf Android 10 umzusteigen.Ich fürchte, ich kann Ihnen bei speziellen Dingen für Android 10 helfen.
Der Weg war "Magisk Module".Ich muss / system / nicht ändern.Ich erstelle nur einige Module, die / system überschreiben oder erweitern.Und es wirkt Wunder auf ein Fabrikbild.Der einzige Grund, warum jemand heutzutage "/ system" ändern möchte, ist, wenn er / sie eine App verwendet, die sich auf / systemänderungen stützt.
@Paschalis Ich führe eine Linux-Umgebung auf meinem Gerät aus.Linux-Tools verwenden häufig `/ etc`, um Konfigurationen zu speichern (falls nicht geändert, um einen anderen Speicherort zu verwenden).Daher finde ich es einfach, eine `/ system`-Partition (wo` / etc` lebt) in R / W zu erstellen, anstatt die Montage zu binden (wie es Magisk tut).Es kommt also auf Prioritäten und Situationen an.


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 4.0-Lizenz, unter der er vertrieben wird.
Loading...