ShiftOS: Native Firewall

[Silva]

Damit Anwendungen die nicht ins Internet müssen, nicht unnötig Traffic erzeugen wäre eine Firewall im OS praktisch.
Klar gibt es dafür Apps, aber sie benötigen entweder Root-Rechte oder missbrauchen die VPN Funktion was es a) unmöglich macht gleichzeitig wirklich mit einem VPN zu kommunizieren und b) immer den schalen Beigeschmack hinterlässt ,es könnte wenn die Verbindung stottert oder die Anwendung abgestürzt ist doch was an der Firewall vorbei gehen.

Es gibt Hersteller die einem die Möglichkeit geben pro App festzulegen ob MobileDaten bzw. WLAN erlaubt sein sollen.
Als kleine aber feine Inspiration um das Interface nicht zu überladen fand ich früher AFwall sehr schön.
Eine Zeile pro App, eine Checkbox pro Verbindungstyp. Primär also "Mobile Daten/WLAN/VPN)
Wenn man das Ganze noch mit einem "Fortschrittenen Modus" kombinieren möchte, kann man sich auch bei Rethink inspirieren lassen, aber da ist die UI sehr überladen und die Sache nicht stabil genug um es für alle empfehlen zu können.

 

[Dwain Zwerg]

Es gibt Hersteller die einem die Möglichkeit geben pro App festzulegen ob MobileDaten bzw. WLAN erlaubt sein sollen.

Das ist bereits in ShiftOS-l integriert (in den App-Einstellungen) und bringt mittlerweile AOSP teilweise standardmäßig mit.

…

Eine echte, fein graduelle Firewall würde ich mir allerdings auch wünschen. Ich glaube aber, dass die Aussage kam, weil dies zu viele Anpassungen an AOSP bedeuten würde, würden sie das nicht in OS-l integrieren. Für den Fall gibt es ja auch schon iodéOS oder CalyxOS. Nur blöd, dass beide noch keine Version rausgebracht haben, die wenigstens eine Daily Driver-Beta ist.

 

[Silva]

Es pro App zu haben anstelle einer gemeinsamen Übersicht ist unpraktisch.

Anpassungen, vielleicht noch nicht einmal. Du hast im Linux Kernel, welcher die Grundlage für den Android Kernel bildet, IP-Filter und eBPF drin.
AFWall+ nutzt ja eingebaute Funktionen und baut nicht wie Rethink alles selber ein.
Was man wohl eher braucht ist: Eine privilegierte Anwendung die das Ganze konfiguriert mit einer ordentlichen grafischen Oberfläche.

In Zeiten in denen Apps sich auf lokalen Schnittstellen austauschen zur Profilbildung:

Fiese Schnüffelei: Meta und Yandex spionierten Nutzer ihrer Android-Apps aus

Wie Sicherheitsforscher herausfanden, schleusen Tracking-Pixel persönliche Daten aus dem Browser an die Apps und Server der Anbieter. Meta hat bereits reagiert.

www.heise.de

sollte man hier durchaus einen weiteren Verteidigungsring ermöglichen mit granulierteren Möglichkeiten als "ja/nein" für WLAN/Mobile Daten.

Gezielte Berechtigungen für Loopback/Localhost und "Lokales Netzwerk" wären hier sehr hilfreich. Chrome hat das als Antwort für die Browserseite auf das LocalMess Debakel angefangen.

 

[Silva]

Da localhost Verbindungen zwischen Apps über TCP/UDP/Sockets nicht über die VPN Schnittstelle geroutet werden ist hier eine Native Firewall klar im Vorteil was die Sichtbarkeit von Dingen angeht die man ggf. wissen und ausbremsen will.

 

[halemmerich]

Was ist das Angreifermodell? Wenn du dich gegen von dir installierte Apps wehren möchtest wird das schwierig. Kommunikation nach außen ist eine Sache, aber zwischen Apps kann ich mir mehrere Wege vorstellen ausserhalb von lokalen Sockets, so dass das schwierig wird. Wenn du Apps benutzen musst, die auf diesem Vertrauensniveau liegen, klingt das für mich ehrlich gesagt mindestens nach Einsperren in einen eigenen User oder direkt auf ein altes Gerät für solche Schweinereien verbannen.

 

[Silva]

Genau das. Siehe den verlinkten Artikel. App macht einen Webserver lokal auf, der Browser der Seiten mit eingebautem Tracking Pixel aufruft verbindet sich mit der App auf dem Gerät und gibt weiter was du dir angeschaut hast.
Klar schwierig, es geht aber eher darum das solche Schweinereien auffallen die die Sandbox für Apps unterlaufen.

 

[Silva]

Wenn ich mir VPN basierte Möglichkeiten ansehe wie RethinkDNS haben wir da im vergleich zur nativen Lösung im Betriebssystem selber immer das Problem dass die Zuordnung von Verbindungen zu Anwendungen nicht präzise ist und teilweise "geraten" werden muss wie das zusammenhängt.
Da ist definitiv Bedarf für eine präzisere Lösung.