Systemd: resolved verkauft User u.U. an Google und Cloudflare

Was so alles ans Licht kommt, wenn man Mailinglisten verfolgt. Quasi in einem Nebensatz hat Herr Pöttering kurz mal erklärt, daß systemd gegen die DSGVO verstößt.

Systemd: resolved verkauft User u.U. an Google und Cloudflare

Die DSGVO legt fest, daß alle Systeme die zum Einsatz kommen, in einer datenschutzfreundlichen Voreinstellung daher kommen müssen. Merkt Euch das mal für später.

Hier erstmal ein Auszug aus dem Posting von Herrn Pöttering:

„Also, people would react very allergic if we’d start sending all DNS traffic to google or so. I mean, you can’t believe how pissed people are that we have a fallback in place that if no DNS servers have been configured at all or acquired via DHCP we fall back to Cloudflare + Google DNS servers. Downstream distros (Debian…) tend to patch that fallback out even…“ (Fedora ML, 29.9. 10:19)

Meint auf deutsch:

„Außerdem würden Menschen sehr allergisch reagieren, wenn wir anfangen würden, alle DNS Verkehr zu googlen oder so. Ich meine, Sie werden es nicht glauben, wie sauer die Leute sind, dass wir einen Fallback haben, der, wenn überhaupt keine DNS-Server konfiguriert sind oder über DHCP erworben werden, greifen wir auf Cloudflare + Google DNS-Server zurück. Downstream-Distributionen (Debian…) neigen dazu, das sogar raus zupatchen …“

Oh, ja, da reagieren wir Menschen allergisch drauf, weil das einen Verstoß gegen den Datenschutz darstellt. Die Debinaleute sehen das ganz richtig. Man kann nicht einfach heimlich am Benutzerwunsch oder Adminunvermögen hinweg Daten an Google oder Cloudflare schicken. Wenn das in einer Firma, einem Verein oder einer Behörde passieren würde, dann wäre das ein DSGVO Verstoß der bestraft würde! Scheinbar hat hier jemand die Jahre 2016-2019 verschlafen, als die EU Gerichte mit so etwas aufgeräumt haben. Zur Erinnerung: US Privacy Shield .. zusammengebrochen, Facebook droht mit Rückzug aus der EU, Google & MS verlegen Ressourcen in die EU, damit sie weiter im Spiel bleiben können und dann kommt ein Systemd daher, der die DSGVO unterminiert.

Man stelle sich mal vor, eine größere Firma in der auch Linux als Desktop zum Einsatz kommt und dann steht in irgendsoeiner hart gecodeten .so drin, sie soll Google kontaktieren. Für alle die nicht wissen, was Datenschutz in Firmen heutzutage bedeutet:

  1. Zuerst muß man mal ermitteln wohin was für Daten abfließenund wen das genau betrifft
  2. Dann muß man eine Datenschutzfolgeabschätzung dafür machen
  3. Dann muß man geeignete Schutzmaßnahmen ergreifen.
  4. Das muß als Vorgang mit laufender Nummer in die Datenschutzmappe eingetragen werden.

Jetzt habe ich als Admin also einen DNS Cache für die Firma hingestellt und per DHCP teile ich dieses DNSCache allen PCs mit. Die PCs fragen also meinen DNS Cache und der fragt dann wen auch immer.Das DNS Cache wird also schon eine Reihe von meinen Abfragen so beantworten können, was den Datenschutzvorteil hat, daß der DNS, den das Cache wiederum fragt, nur einen Bruchteil davon sieht und so kein vollständiges Profil erstellen kann. Den DNS Cache ( z.b. nscd ) kann man auch per Round-Robin mehrere andere Server fragen lassen um die Profilbildung weiter zu erschweren.

Der Problemfall

Jetzt funktioniert der lokale DNS aber nicht, weil es ein Update gab, oder die VM abgestürzt ist. Systemd würde jetzt keine gültigen DNS bekommen und Google+Cloudflare fragen. Damit wäre meine komplette Datenschutzabschätzung fürn Arsch. Schlimmer noch ist der Umstand, daß diese Art Datenfluß als Vorgang überhaupt gar nicht in meiner Datenschutzmappe vorkommt. Zum Glück ist das ein minder schwerer Fall, den der Datenschutzbeauftragte selbst regeln kann, indem er den Vorfall in die Mappe einträgt und Maßnahmen ergriffen werden, dies zukünftig zu verhindern.

Sollte aber ein Datenschutzaudit ergeben, daß es diesen Abfluß gibt ohne das das intern gefunden wurde, sieht die Sache schon anders aus. Je nach Umfang könnte die Datenschutzbehörde ein Bußgeld verhängen und das nur weil einer, den keiner in der Firma kennt, meinte schlauer sein zu müssen, als alle anderen. Na danke!

Jetzt kommt der nächste Oberschlaue mit dem Hinweis, daß bei DSL ja eh alle die gleiche IP von der Firma haben und individuelle Profile gar nicht erstellt werden können und außerdem wären das ja keine privaten Domainanfragen. Das fällt bei größeren Firmennetzen seit IPv6 unter „Es war einmal..“ . Wenn ich einen Businesszugang mit einem reinen IPv6 Netz bekommen, habe ich einen ganzen Block zur Verfügung. Dies Netz kann ich direkt an alle Pcs durchreichen, denn dann habe ich kein NAT Problem mehr. Per Firewall kann ich den Direktzugang zu den Pcs sperren, kein Problem und wenn doch mal jemand von außen drauf muß, wären individuelle Freigaben möglich. Das muß man als Admin natürlich auch mit IPv6 nicht so machen, aber es wurde mal so vermarktet, als für IPv6 geworben wurde.

Das die meisten am Arbeitsplatz auch privat surfen, braucht man wohl kaum noch erwähnen.

Die Technisch -Organisatorischen Maßnahmen zum Datenschutz einer Firma ( TOM ) beinhalten alle Maßnahmen die man so als Firma macht und wenn da steht, wir leiten DNS über ein Cache zum minimieren von Profilbildungen, dann kann man da schlecht ein Linux betreiben, daß sich da nicht dran hält, oder seht Ihr das anders? Linux muß also auch in der Datenschutz freundlichen Einstellung daher kommen, was damit einen Einsatz von systemd-resolved ausschließt, da man sich da ja nicht drauf verlassen kann wie man oben sieht.

Update

Ein Leserbrief erreichte mich vorhin. Hier ist der Link, in dem das Fallbackfeature bei Systemd besprochen wird: https://github.com/systemd/systemd/pull/11666

Und gleich noch die Diskussion, wieso CloudFlare DNS besser wären: https://github.com/systemd/systemd/issues/8899

So richtig viel Gegenwind gabs aus der Peergruppe anscheinend nicht.

Fedora 33: der Wechsel zu systemd-resolved schaltet DNSSEC aus

Wow, was für eine Hammermeldung. Damit hatte vermutlich niemand gerechnet, daß der Wechsel zu systemd-resolved als DNS Resolver des Systems einfach mal die einzige Sicherheitsmaßnahme im DNS aushebelt, die überhaupt spürbar Sicherheit gebracht hat 🙂

Fedora 33: der Wechsel zu systemd-resolved schaltet DNSSEC aus

„Seit heute morgen 6:44 Uhr wird zurück geschossen“ :  Paul Wouters, bekannt aus dem Bereich Transparenz und Sicherheit der IETF, updatete seinen Server auf Fedora 33, was er quasi sofort bereut hat. Mit dem Wechsel kam die Umstellung auf systemd-resolved, über den wir vor Monaten in der Fedora Mailingliste gesprochen hatten und ich eigentlich der Meinung war, daß die Umstellung der /etc/resolv.conf hin zu systemd-resolved in der Form gar nicht kommt.

Man merkt, daß Paul bei seinem Posting an die Fedora-Devel-Mailingliste auf Krawall gebürstet war, und das vollkommen zu Recht. Seine ganzen Serverdienste benutzen DNSSEC um die Verbindungen zu Mailserver, VPN usw. abzusichern, so daß niemand für seine Dienste eine MITM-Attacke fahren kann und dann kann der eingesetzte DNS-Resolver plötzlich kein DNSSEC mehr:

„It is my opinion as a long time DNS RFC author and package maintainer that systemd-resolved is not a suitable DNS resolver. Downgrading DNSSEC allowing local DNS to bypass DNSSEC is bad enough, but I read on:

https://fedoraproject.org/wiki/Changes/systemd-resolved

that DNSSEC is now completely disabled. Again, this is completely unacceptable. DNSSEC is part of the core of DNS protocols.“ (Paul Wouters)

Ich hätte nicht gedacht, daß jemand wirklich so verrückt wäre, Millionen von PCs mit einem DNS-Resolver aus der Steinzeit zuversehen, wo das Update doch eine Verbesserung und kein Rückschritt sein sollte. Seinen weiteren Ausführungen kann man sich nur anschliessen:

„This change is harmful to network security, impacts existing installations depending on DNSSEC security, and leaks private queries for VPN/internal
domains to the open internet, and prefers faster non-dnssec answers over dnssec validated answers. It fails various types of queries,
misimplements part of the DNS protocol. Not only according to me, but to 20years+ developers of the bind software as well.

The first mandatory step is to not disable DNSSEC. If I put on my security hat, I would actually have to look into filing a CVE for Fedora 33.“ (Paul Wouters)

Und der Mann weiß was er da schreibt, er hat 20 Jahre an Bind mitgeschraubt. Zum Glück für uns ist nichts in Stein gemeiselt, daher jetzt die Befehle, um nach dem Upgrade für Ordnung zu sorgen:

sudo rm -f /etc/resolv.conf
sudo ln -sf /run/NetworkManager/resolv.conf /etc/resolv.conf
sudo systemctl disable –now systemd-resolved.service
sudo systemctl mask systemd-resolved.service
sudo systemctl reboot

Damit haben wieder die DNS Einstellungen das sagen, die der User beim Anlegen der Netzwerkverbindung getroffen hat. Ich finde ja schon lange, daß der Systemd sich deutlich zu weit aus dem Fenster hängt. Das ist ein Bootsystem und kein eigenes Betriebssystem Leonard! Aber stellt sich doch glatt raus, daß der resolved vom systed das könnte, wenn man es nur einschalten würde, was es per default nicht ist :facepalm:

 

Das Update ist der Anfang vom Ende

Noch letzte Woche habe ich einer Linux-Usergroup Sitzung die Material-Shell Erweiterung für Gnome gezeigt und für sinnvoll erklärt. Zum Glück bin ich kein Politiker.

Das Update ist der Anfang vom Ende

Das keine 5 Tage später mein vorsichtiges Empfehlen dieser Erweiterung zu einem rüden Stop kommen würde, konnte da noch keiner ahnen. Leider kann ich Euch nicht zeigen, wie die Material-Shell funktioniert, da sie sich sehr erfolgreich durch ein Gnome-Extensions-Update selbst zerbröselt hat.

Trotz diverser Versuche, inkl. Neustarts von Gnome, war ich nicht in der Lage die Erweiterung auf diesem Benutzeraccount wieder zum Laufen zu bekommen. Da darf man gespannt sein und vermutlich alles, was mit der Erweiterung zu tun hat wie „Config“,“Cache“,“Erweiterung selbst“ aus den Verzeichnissen löschen und dann von vorn anfangen. Ohne diese Maßnahme kommt es zur sinnlosesten Fehlermeldung ever: „Error“

Damit kann man als Gnome-Benutzer natürlich nichts anfangen, außer die Erkenntnis gewonnen zu haben, daß es sich da jemand sehr einfach gemacht hat. Zum Glück kann man mit der Looking-Glass Konsole von Gnome doch etwas erfahren, aber halt nur als Eingeweihter in die Tücken der Gnome-Erweiterungen. Diese sind z.Z. in Javascript geschrieben und können daher tatsächlich von Webentwicklern geändert werden, die JS verstehen. Das hilft zwar nicht immer, weil es kein Browser-JS ist, aber kleinere Fehler kann man beheben.

Eine Debugkonsole von Gnome mit InhaltWir haben also den Fehler „TypeError: GObject.registerClass() used with invalid base class ( is Source )“

Scheint also ein Programmierfehler zu sein in der neuen Version. Das hätte ja eigentlich beim Testen mal auffallen müssen. Mit einem Trick kann man das ganze „Retten“:

Mit Firefox ladet Ihr jetzt die V4 der Gnome-Erweiterung für die passende Shellversion (34) runtern:

Die gespeicherte Version ist ein ZIP File, das packt Ihr einfach aus und wechselt in das erstellte Verzeichnis.

Ihr macht nun einen zweiten Dateibrowser auf und navigiert nach: „./local/share/gnome-shell/extensions/material-shell@papyelgringo“ . Alles was Ihr findet wird gelöscht, der Ordner bleibt.

Dann kopiert Ihr den Inhalt des frisch ausgepakten ZIP Files in das leere Verzeichnis:

Zwei Dateibrowser mit Inhalt einer Gnome-Erweiterung beim kopieren von Dateien

Drückt „ALT+F2“ und gebt „r“ ein. Das startet Gnome neu und siehe, die Material-Shell geht wieder. Problem gelöst, aber Updates gibt es erstmal keine mehr 🙂