Ich verwende den kostenlosen SSHelperSSH-Server auf meinem Telefon, um SSH-Zugriff zu erhalten. Die Anwendung verhält sich jedoch nicht richtig, SELinuxwenn sie auf EnforcingModus eingestellt ist, scheint aber in Ordnung zu sein, wenn sie PermissiveModus verwendet. Dies ist nicht überraschend, da es unter CyanogenMod entwickelt wurde, wodurch der Autor sich dieser Probleme für spätere SELinux Enforcing Stock AOSs nicht bewusst ist.
/dev/pts/NDas Problem tritt auf, wenn die App während einer SSH-Verbindung versucht, ein Pseudo-Terminal zuzuweisen . Dies schlägt fehl und die resultierende Shell ist für die Entwicklung im Wesentlichen unbrauchbar. Nachdem ich viel Zeit damit verbracht habe, dieses Problem aufzuspüren, wie es HIER dokumentiert ist . Wo ich die folgenden "Fehler" in der /data/misc/audit/audit.logDatei gefunden habe:
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
Da ich jedoch noch keine Erfahrung mit SELinux und seinen mysteriösen Schutzmechanismen habe, könnte ich wirklich etwas Hilfe gebrauchen. Ich weiß nicht einmal, ob das wirklich das Problem ist, ich vermute es nur. Die Überprüfung der Berechtigungen der obigen Datei ergibt:
# 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
Aber das contextscheint überhaupt nicht mit dem übereinzustimmen, was im Log angezeigt wird .
Wie kann ich diese Berechtigungen korrigieren, damit sie im Erzwingungsmodus gut mit SELinux funktionieren ?
(Außerdem, welche Tools und Dateien sind in Android verfügbar, um dies zu beheben?)
Ich denke, das Problem könnte die standardmäßige "unbeschränkte Domäne" sein, die die Binärdatei ausgeführt wird, wenn keine Richtlinie angegeben ist.
Ein Versuch, den ich versuchen würde, wäre, den sshelper_sshd(ich glaube, es ist der sshd-Server?) irgendwo auf der /systemPartition zu verschieben ( /system/sbin/?)
Ich denke, das beste und aktualisierte Dokument, das Sie lesen sollten, um sich mit der SELinux-Implementierung auf Android (SEAndroid) zu befassen, ist How-To SU .
Hier ein Auszug aus Kapitel 5.4.4. Android 4.4.3
Ein gutes Beispiel dafür, dass die uneingeschränkte Domäne nicht allmächtig ist, ist das Ausführen von Dateien aus /data. Ab Android 4.4.3 ist dies aus der unconfined Domain nicht mehr möglich (siehe #74082 und #78801).
Die etablierte Praxis, Binärdateien und Skripte in Ihr APK aufzunehmen, sie nach /data/data/[package]/files/ zu extrahieren oder sie in /data/data/[package]/lib/ zu platzieren und sie von dort über einen su-Aufruf auszuführen wird nicht mehr out-of-the-box funktionieren. Es gibt zwar andere Problemumgehungen (z. B. Kopieren in und Ausführen von rootfs), aber eine Lösung besteht darin, Kontexte in einen Kontext zu wechseln, der nicht in der uneingeschränkten Domäne liegt (z. B. u:r:untrusted_app:s0, der Kontext, in dem der Rest Ihrer App wahrscheinlich ist). laufen als). Sie müssen jedoch umfangreiche Tests durchführen, um festzustellen, ob alle Anrufe, die Sie tätigen möchten, immer noch in dem von Ihnen gewählten Kontext ausgeführt werden, und Sie müssen möglicherweise einige andere ausprobieren, um die gewünschten Funktionen zu erhalten.
Beachten Sie, dass das Ausführen von Dateien in /data weiterhin wie von Ihrer App erwartet funktioniert, wenn Sie nicht versuchen, sie als Root auszuführen.
Vi0
nicht2qubit