Bedeutung/Auswirkung der SuperSU-Berechtigung?

[Agent Smith]

Hallo zusammen,

über Google konnte ich keine zufiredenstellende Erklärung finden, daher probiere ich es mal auf diesem Weg.
Ich habe ein gerootetes Galaxy S Advance und möchte gern wissen, welche Auswirkungen die SuperSU-Berechtigung (Vollzugriffsrechte auf alle Gerätefunktionen und Speicher) hat, die manche Apps fordern.

Es ist mir schon klar, dass das wohl die Berechtigung für den Root-Zugriff ist. Verstehe nur nicht, wieso das manche Apps fordern (z.B. ES DateiExplorer, Titanium Backup, ...) während andere Root-Apps wie z.B. Dateinmanager (ist ebenfalls ein Root-Explorer) oder Droidwall diese Berechtigung nicht fordern.

Erlaubt diese Berechtigung den Apps einen Root-Zugriff ohne vorherige Freigabe über die SuperSU-App oder wie ist das zu verstehen?

Vielen Dank schon mal für eure Antworten!

 

[Lion13]

SuperSU (wie auch Superuser) sind ja quasi die Schnittstelle zwischen den Apps und dem Root-Zugang - von daher stimmt deine Aussage, daß die App den Zugriff auf Root-Funktionen regelt, entweder erlaubt oder ablehnt.

Eine automatische Root-Nutzung ist mir persönlich bislang nicht bekannt, und meine 4 Android-Geräte waren bzw. sind alle gerootet; manche Apps fragen aber erst nach Root-Rechten, wenn sie diese auch explizit nutzen; ein Dateimanager wie der "Root Explorer" kann ja auch ganz normale Datenverwaltung z.B. auf einer SD-Karte ausführen und benötigt dafür keine Root-Rechte.


Dein Thread wäre aber im Root-Bereich wohl besser aufgehoben.
Allgemeines zu Root, Kernel und Customs-Roms auf Android-Hilfe.de

 

[LouCipher]

Und genau da ging es jetzt auch hin.

 

[mizch]

Da geht einiges durcheinander: Dein „Dateimanager (Root-Explorer)” kann kein Root-Explorer sein, es sei denn, er fordert Root-Rechte an. Ich nehme an, die Bezeichnung in Klammern hast Du Dir ausgedacht, weil er ähnlich aussieht, kenne ihn aber nicht.

Android schottet seine Anwendungen gegeneinander ab. Sie können miteinander nur begrenzt und über die von Android dafür vorgesehenen Wege kommunizieren. Das hat Sicherheitsgründe und wird unter dem Begriff „Sandbox” zusammengefasst. Jede App hat ihren eigenen Sandkasten, in dem sie beliebig spielen kann, ohne die anderen Apps in ihren Sandkästen zu stören. Sie kann sie nicht mal beobachten und muss sich an den Spielplatzleiter (Android) wenden, wenn sie von anderen etwas möchte. Der bringt das dann in geordnete Bahnen und verhindert, dass etwas Böses angestellt wird.

Root ermöglicht es, diese Grenzen aufzubrechen. So kann ES, sobald es Root-Rechte hat, die Sandkästen der anderen beobachten und sogar drin rumpfuschen. Konkret: mit ES kannst Du nach /data/data gehen, wo sich die Daten (Sandkästen) aller Apps befinden, mit Deinem „Dateimanager” (wenn er keine Root-Rechte anfordert) aber nicht oder Du bekommst höchstens ein leeres Verzeichnis angezeigt.

Titanium muss an die Daten anderer Apps kommen und an die Apps selbst, sonst kann es sie nicht sichern. Es braucht also Root, weil es sonst davon abgeschottet ist. Droidwall verwendet Kernel-Funktionen, die Apps ganz allgemein aus guten Gründen gar nicht zugänglich sind, und braucht deshalb – im Gegensatz zu Deiner Aussage – ziemlich sicher Root.

Apps erhalten ohne Freigabe durch SuperSU keine Root-Rechte. Dein letzter Satz trifft also nicht zu. Für Apps geht der Weg zu Root immer über SuperSu (oder das ältere SuperUser). Die delegieren den eigentlichen Vorgang des Rootens an su, was ein kleines Binary ist und von Nicht-Apps (wie in der Kommandozeile) direkt aufgerufen werden kann.

 

[Agent Smith]

Erstmal danke an euch beide (wo ist eigentlich dieser Danke-Button?)

Da geht tatsächlich einiges durcheinander, hab mich wohl etwas mißverständlich ausgedrückt.
Mir geht es nicht direkt um die App "SuperSU", sondern um die Berechtigung "SuperSU" (s. Screenshot).
Diese fordert der "ES Datei Explorer", mein alternativ benutzter "Dateimanager" (s. hier: https://play.google.com/store/apps/details?id=com.rhmsoft.fm) aber nicht. Sowohl der "ES Datei Explorer" als auch der "Dateimanager" sind als Root-Explorer benutzbar, natürlich erst nach vorheriger Freigabe durch die App SuperSU.

Droidwall fordert diese Berechtigung auch nicht, obwohl Droidwall selbstverständlich Root-Rechte benötigt. Ich versuche nur zu verstehen, wofür diese Berechtigung benötigt wird.

 

[mizch]

Diese Berechtigung ist für die Zukunft gedacht und wird derzeit noch ignoriert.

 

[Agent Smith]

Sorry, muss nochmal nachhaken...
Welche Funktion soll diese Berechtigung in der Zukunft haben und ab wann?
Wäre da dann denkbar, dass sich Apps mit dieser Berechtigung Root-Zugriff holen, ohne vorherige Freigabe über die SuperSU-App?

 

[u.k-f]

Wäre da dann denkbar, dass sich Apps mit dieser Berechtigung Root-Zugriff holen, ohne vorherige Freigabe über die SuperSU-App?

Nein, eher umgekehrt: Wenn eine App nicht schon bei der Installation sich dei Berechtigung holt, das su-Binary aufzurufen, kann sie es später nicht zur Laufzeit.

Ich umreise mal kurz, wie das Ganze dann implementiert werden könnte:

Wie funktionieren App-Berechtigungen unter Android?

Android verwendet für jede App einen eigenen 'Linux-User' mit eigener User-ID. Wenn die App gestartet wird, wird der Prozess dieser App dann als der entsprechende 'Linux-User' gstartet. Zu jeder App gibt es unter /data/data/package.name.der.app/ ein Verzeichnis, das diesem Linux-User gehört und in der (fast) nur dieser reingreifen (lesen/schreiben) darf (root natürlich auch). Somit wird sichergestellt, dass jede App genau nur in 'Ihrem' Verzeicnis rummachen kann/darf.

Gemeinsame Resourcen (z.B. die Sd-Karte /sdcard) gehören bestimmten System-Usern und sind dementsprechenden User-Gruppen zugeordnet (im Falle der SD-Karte ist das (glaube ich) der User media und die Gruppe media.) Daher sind Schreib und Leserechte auf die SD-Karte an die Gruppe media vergeben.

Wenn nun eine App bei der Installation beantragt, dass sie auf die SDKarte zugreifen will, wird der Linux-User, welcher der App zugeordnet ist, in die entsprechende Gruppe aufgenommen. (Ein Linux-User kann in mehrere Gruppen aufgenommen sein.) Daruch erhält der User Zugriff auf alles, was der entsprechenden Grupp zugeordnet ist (z.B. die SD-Karte).

Wie würde man dieses nun für den SuperUser-Zugriff verwenden?

Im Moment ist es so, dass jeder User auf das su-Binary zugreifen kann (Ausführungsrecht für alle). Dass nicht jeder SuperUser-Rechte gewährt bekommt kommt erst dadurch, dass das su-Binary bei der SuperUser oder SuperSU-App anfragt, ob diesem 'Linux-User' und damit dieser App Zugriff gewährt werden soll.

Um den Zugriff auf SuperUser Zugriff auf die Apps zu beschränken, die schon bei der Installation SuperUser-Anfragen als Bereichtigung bekommen haben, muss man nun eine Gruppe 'SuperUser-Anfrage' anlegen. Da die 'SuperUser Anfrage über das su-Binary stattfindet, müsste man einfach den Zugriff auf das su-Binary von Ausführungsrecht für alle auf Ausführungsrecht für die 'SuperUser-Anfrage-Gruppe' beschränken. Die Apps, die dann bei Installation das Recht 'SuperUser-Anfrage' bekommen, werden dieser Gruppe zugeordnet. Damit hätte immer noch nicht jede App automatisch Zugriff auf SuperUser-Rechte, aber die Apps, die nicht die entsprechende Berechtigung bei der Installation beantragt haben, könnten garnicht erst anfragen.

MfG Uwe

 

[Agent Smith]

Super, Danke für die ausführliche Erklärung! Das hat meine Frage beantwortet.
Leider steht mir als Neuling der Danke-Button noch nicht zur Verfügung, daher Danke auf diesem Weg.

 

[u.k-f]

Gerne doch

Das einzige was ich genau so gerne mache, wie an Technik rumzufrickeln, ist darüber reden oder schreiben...

MfG Uwe