Profilübergreifende Kommunikation unter Android per Netzwerk-Interfaces (verhindern?)

auf Wunsch als Off-Topic eröffnet

Gut,

ich sehe das im Kontext sehr wohl in Bezug zu obenstehendem Thema, die „Kommunikation“ war mit an Sicherheit grenzender Wahrscheinlichkeit profilübergreifend wirksam und damit schwerwiegender aufgrund des unbegründeten Fühlens gewahrter Sicherheit.

Im Bild ein Samsung, auf dem standardmäßig auch noch drei Meta-Apps ungenutzt, aber wohl laufend, da die Option zum Stoppen aktiv war, und nicht sichtbar unter Apps in den Einstellungen, sowie die deaktivierte Youtube-App im normalen Profil hatte.
„Meta App Installer“(com.facebook.system)
„Meta App Manager“(com.facebook.appmanager)
„Meta Services“(com.facebook.services)
alle lt. Einstellungen „von Meta App Installer geladene App“, wohl noch in mitgelieferter Version

Es handelt sich dabei um ein Gerät mit einem durch den Arbeitgeber administriertem Arbeitsprofil.
Letzten Aktualisierungen wurden vor ca. 2 Wochen eingespielt.

Im Bild Edge

eben im Test tat es doch auch Chrome

ansich blockiere ich JS, nur Ausnahmen sind aktiviert für benötigte Seiten, aber für den Test für die Seite mal aktiviert. (Das ist aber nicht geforderter bzw. umgesetzter Standard)

WebRTC funktioniert(e) anscheinend wunderbar profilübergreifend.

Nur mal so anmerken wollend.

Das ist nicht nur für Privacy von Privatpersonen von Belang, sondern auch für Firmen und in dem Zusammenhang dann auch für deren Angestellte.

Wobei ich auch anmerken muß, daß mittlerweile die neuen Firmengeräte volladministriert sind, also nur ein Profil mit „device owner“ ohne Arbeitsprofil.

Bin mal gespannt, ob diese Tage noch ein Neuaufsetzen erfolgen wird.

PS:
In dem Zusammenhang möchte ich noch anmerken, daß VPN-Apps (zum Blocken) beim Wechsel zwischen verschiedenen normalen Profilen (nicht vertraulich, bzw. Arbeitsprofil) der eben nicht genutzten Profile zumindest in Vergangenheit auch gern mal ohne Zutun beendet wurden.

(Das war der Grund, warum ich die normalen zusätzlich möglichen Profile ungern nutze, fiel mir vor kurzem wieder ein.

Beim StockRom wurden die vom Hauptprofil abweichenden Profile beim Zurückwechseln in der Regel auch nicht wieder beendet.)

PPS:

ich vergaß die App zu erwähnen, die in den Bildern ansonsten noch erschien, die den Server spielte,

„ScreenStream“ von F-Droid(info.dvkr.screenstream)

aus dem Ursprungsthread (s.o.)–>

Mit Webseiten, die Inhalte einbinden, die lokal zugriffen, kann ich nicht dienen, auch nicht mit Codeschnipseln.

„WebDAV“ in den zwei freien Versionen würde ich aufgrund der zusätzlichen Internetverbindungen nur bedingt empfehlen zum Test. Man sieht auch nicht unbedingt alle Interfaces.

Ansonsten z.B. oben genannte App „ScreenStream“ aus Play Store oder von F-Droid (unerwünschte Merkmale beachten, bezieht sich aber wohl auf dessen Webseite)

hat sehr umfangreiche Konfigurationsmöglichkeiten, u.a. kann man den Server an alle Netzwerkinterfaces binden
(ohne eingeschaltetes JS im zum Anschauen benutzten Browser sieht man man nur das Begrüßungsbild, theoretisch könnte man auch in diesem.Zuge wieder ein unerwünschtes Element aufrufen)

Vielen Dank für die Hinweise! Muss das jetzt alles erst mal an meinem Gerät ausprobieren. Das kann ein paar Tage dauern.

Schön wäre eben, wenn man wie unter Linux Zugriff auf ip(6)tables hätte, über die Adresse des anderen Interfaces ist der Zugriff weiterhin möglich, aber prinzipiell könnte man alle Verbindungen intern blocken, man sollte wissen, was man tut, mit root-Rechten wäre das möglich.


(quick&dirty nur für 127.0.0.1:22 im neuen integrierten Linux von Android(eine WebView-App)

Ein anderer Ansatz wäre wie es Firefox praktizieren möchte →

wenn das eine Lösung darstellen soll …

… wie „ScreenStream“ den einen für seinen Zweck einfach alle „involvierten Ports“ (auf allen Interfaces(sicher ist sicher(?)) selbst belegen, dann ist das für alle Apps in allen Profilen wirksam, die keine anderen Apps killen können.

Mit Shizuku und Termux könnte man vielleicht auch netstat regelmäßig scannen lassen und lauschende Ports und deren verursachende UID mitmeiseln, zur Ursache auflösen und sich für manuelles Eingreifen bemerkbar machen, eine Whitelist führen, etc. pp.

Ob möglich könnte vielleicht ein Terminal-Kundiger verifizieren.

Weil nicht nur hier Einwände kamen, man könne nicht alles verrammeln. Natürlich werden auch lauschende Ports gebraucht, z.b. für per Tethering angebundener Geräte, z.B. für DNS und DHCP, dann auf dem jeweiligen Interface und nur von dort. Aber das ist doch kein Hexenwerk, erwünschte von unerwünschten zu unterscheiden. Die wenigsten benötigen lokal Dienste, die per Netzwerk oder von lokal zugänglich sind. Hier stellt sich das Problem, daß sich die Quellen unerwünschter Verbindungen lokal nicht zuverlässig blocken lassen ohne die Ursache gleich zu killen.

GrapheneOS hat das Thema auf dem Schirm in ihrem Issue Tracker:

use isolated loopback network interface for each profile by default

https://github.com/GrapheneOS/os-issue-tracker/issues/4772

1 „Gefällt mir“

Gilt dann für den Vanadium-Browser und den darauf basierenden WebView, optional alle privaten Interfaces. → „Vanadium provides a user-facing setting at Privacy and security > WebRTC IP handling policy. From least to most strict: Default Default public and private interfaces Default public interface only Disable non-proxied UDP For Vanadium, „Disabled non-proxied UDP“ is the default.“

Beim WebView sind nicht-GrapheneOS-User ohne root wieder raus.

Danke für den Link, darüber bin ich dann auf obiges gestoßen und im weiteren auf →
„This change would be too large for GrapheneOS to implement it on their own.“

Man könnte allerdings ein Monitoring wie oben angesprochen implementieren und warnen.

GrapheneOS könnte das per netfilter implementieren.

ich nur irgendwie per Workaround.

wenn zum Beispiel wie bei mir hier wiederholt, aber anscheinend nicht dauerhaft die Google Play Dienste auf Port 64660 lauschen, wäre es doch eine Möglichkeit, selbst den Port zu öffnen, im Test funktioniert hier z.B. →

nc -l 64660 (netcat z.b. in Termux über das Paket netcat-openbsd installierbar), wenn Termux beendet wird, ist der Port aber auch wieder frei, freilich könnte man den auch über die shell öffnen, dann hält das vllt. bis zum nächsten Reboot

gegebenenfalls für weitere Ports, evtl auch direkt umleiten ins Nulldevice, damit es nicht zum Risiko wird

Momentan habe ich es mal für den Port gestartet und lasse es in Dateien unter /data/local/tmp/XXXX schreiben, in die Termux schreiben darf und schau später mal, ob da was ankommt.

interessant auch die Vermutung von „ignoramous“ →

ignoramous GrapheneOS
Curious: Would turning ON (on Android 11+) VPN Lockdown mode („Block connections without VPN“) prevent the technique used by Meta (which is prevented if Chrome couldn’t bind to all interfaces)? Does the loopback (127/8) traffic go through the TUN device when VPN is in Lockdown mode? ryrona Web sites are not supposed to be able to communicate with installed apps on your device in any way at all. This has never been true (see: deeplinks, as one example)?

kann ich für RethinkDNS oder NetGuard aber nicht bestätigen, da kommt es wohl auch auf die Einstellungen in der jeweils verwendeten App an, bei mir gibt es nur den „Lockdown mode“ und hier war die Verbindung zu localhost und den anderen privaten Interfaces nicht gestört, anderseits habe ich hier auch kein GrapheneOS

OT: aber immer wieder (un-)schön →


(ich weiß, man muß auch mal Vertrauen haben können)

ein Link zu Google →
„Android devices generally do not require inbound ports opened on the network to function correctly.“/„In der Regel müssen Eingangsports im Netzwerk nicht geöffnet sein, damit Android-Geräte richtig funktionieren.“


OT bezüglich „Kommunikation per Netzwerkinterfaces“:

Natürlich gibt es auch die Kommunikation per „Datei“ als Bestandteil des Konzeptes von Linux „Alles ist eine Datei“.

Warum nicht direkt per Datei?

Vielleicht kommt dem ein oder anderen der Ordner „/data/local/tmp“ noch in Bezug auf „dirty cow“ bekannt vor.

Man kann auch mit Rechten der Shell Ordner dort anlegen, Dateien darin anlegen, deren notwendige Rechte ändern und jeden dort schreiben/lesen/ausführen lassen. Derjenige muß dann nur Namen und Ort wissen.

Die Ordner/Dateien dort überstehen auch Reboots und Upgrades. Imho die unter /tmp nicht.
[/OT]