Tablet: Fedora 33 Beta auf Surface Pro 4

Wieso würde ich Euch eine Nachricht antun, daß Fedora 33 Beta Linux auf meinem Tablet läuft? 🙂

Tablet: Fedora 33 Beta auf Surface Pro 4

Also ein Grund ist, das es Gnome 3.38 hat:

der andere Grund ist, daß es bis vor 10 Minuten nicht ging 😉

Im LiveImage von Fedora 33 kommen neue Grub Bootloader zum Einsatz und die starten nicht auf dem normalen Surface Pro 4, weil das wohl ein Firmware Update braucht, was es natürlich als reines Linux System nicht bekommen wird.

Ihr entsinnt Euch vielleicht an diesen Artikel: Fedora Guide – Falls der Grub2 Fix bei Euch versagt

Grub 2 hatte da einen bedauerliches Problem. Das wirkt sich nun scheinbar auf das Liveimage aus.

Beheben lies sich das durch ein Transplant der Grubbootloader in der Boot-Partition von F31 auf F33. Fedora ist dran, wird da aber ein kleines Problem haben, weil das Firmwareupdate von Microsoft kommen müßte.

GGf. können die Jungs vom Surface Kernel Projekt helfen, aber das wird sich erst in den nächsten Tagen entscheiden, denn noch wissen die nichts von Ihrem Glück.

PS: ich staune. Mein nur zu 77% gefüllter Akku soll angeblich noch 6 Stunden bei 4 Kernen und aktivem Turbo halten. Wie lange wäre das denn, wenn der voll wäre??? und schon sprang er auf 5h 45m. Verdacht: Es lügt mich in freundlicher Absicht an 😀

Hmm.. „Suspend“ funktioniert, der wacht sogar sofort wieder auf, wenn man auf den Power-Knopf drückt. Leider killt er dabei den Wifichip 🙁

UPDATE:

Stellt sich gerade raus, es ist wohl ein Timing Problem, denn 1 von ca. 10 Boots klappt und je schneller man bootet, nachdem der USB Stick eingesteckt ist, desto wahrscheinlicher der Start. Ich hoffe wir finden das raus. Der Grubsfiles sind da wohl nicht von Bedeutung.

CoronaChroniken: CVE für die Corona API von iOS und Android

Liebe Maskierte,

die meisten Leser, die wegen Corona hier sind, werden CVE-Nummern nicht kennen. Diese werden in der IT vergeben, wenn eine Sicherheitslücke gefunden wurde. Zu der Nummer gehört dann auch eine Risikoeinschätzung. Für die Corona-Melde-Api in iOS und Android wurde so eine Nummer beantragt, vergeben und bewertet.

CoronaChroniken: CVE für die Corona API von iOS und Android

Letzte Nacht erreichte uns auf der Full-Disclosure Mailingliste eine entsprechende Meldung von Dirk-Wilhelm van Gulik:

CVE-2020-24721: (Corona) Exposure Notifications API for Apple iOS and Google Android risk of coercion/data leakage post notification  / CVSS v3.1 score: 5.9

Die Schwachstellen wurden als „Mangel zum Schutz gegen Zwang“ und ein Informationsleck beschrieben, kurz zusammen gefasst: Selbst wenn die App gelöscht wird, wird in dem Teil des Betriebssystems in dem die ganze Technik für das Senden und Empfangen der Bluetooth untergebracht ist, der letzte Zustand gespeichert, weil die Anwendung darauf keinen Zugriff hat. Das bedeutet, ist die App einmal drauf und hat aktiv Daten gesendet oder empfangen, kann man das letzte Ergebnis nicht mehr vom Handy löschen. Damit kann ich nicht verhindern, daß jemand z.b. meine Aussendung „Ich bin ein Coronainfizierter“ aus dem (beschlagnahmten) Handy auslesen kann. Gleiches gilt für den Umstand, das man einen Hinweis eingeblendet bekommen hat, daß man einem Infizierten begegnet ist. Das widerspricht natürlich dem Gedanken, daß man seinem Handy trauen kann.

Bei Android und iOS gibt es implementierungsabhängige Abweichungen, aber im Prinzip leiden beide unter dem gleichen Problem. Eine Lösung, außer niemals die Apps zu benutzen, gibt es leider für Euch nicht, denn nur Google und Apple können das Problem lösen.

An die 16 Millionen die es schon installiert haben: Ihr seid gewarnt worden! Selbst Schuld.

Verursacht wird dies, weil das Handy immer die gleichen Identifikationsmerkmale erzeugt, die müssen ja schliesslich eindeutig sein, und dies natürlich auch dann tut, wenn jemand anders die App wieder installiert. Die Datensammlung scheint ~30 Tage lang zu laufen, also erst nach dieser Zeit kann man sicher sein, daß zumindest keine „Sie sind einem Coronainfizierten begegnet“ Meldungen mehr kommen. Das andere Problem ist nicht lösbar, außer die Daten werden im internen Speicher des OS gelöscht. Da hilft dann nur der Factory-Reset.

Nun ist das bereits im Januar bekannt geworden, weil es ein Systemimmanentes Problem ist (sieht Zeitstrahl unten). Warum die Apps trotzdem gemacht wurden und Google und Apple nichts dagegen getan haben, überlasse ich mal Eurer Fantasie, sofern Ihr welche habt. Auch wenn die Hinweise aus Holland kommen, die in den Handies verbauten Frameworks sind immer die gleichen, also gilt das auch für unsere deutsche App.

Glücklicherweise, wurde die App ist ja laut Amtsärzten derzeit als zweckfrei angesehen, also löscht die jetzt einfach und hofft darauf, daß Ihr in den nächsten 30 Tagen nicht von jemandem gezwungen werdet, sie erneut zu installieren.

Für Interessierte:

Variations of this flaw have been documented by the DP3T team in their academic paper. It was found it the Apple/Google implementations during the build of the dutch ‚Corona Melder‘ app (https://github.com/minvws).

2020-01-18 first known description of this class of issues
2020-04-03 first paper by DP3T team published.
2020-05-06 confirmation of this issue with Google
2020-05-07 confirmation of this issue with Apple
2020-08-13 final written/formal questions sent on request (#115 and 115.bis) as a vulnerability report.
2020-08-13 confirmation vendor. 2020-08-27 CVE issues by MITRE
2020-09-13 Request vendor to provide CVE/start FD.
2020-09-15 Versions under embargo sent to google/apple. Confirmation of receipt and reference # for both received.
2020-09-15 Full disclosure timeline setting process started.
2020-09-22 Reminder to google/apple & request to submit their preferred timeline/disclosure approach.
2020-09-25 Deadline to provide timeline preferences and feedback passed.
2020-09-29 Vendor informed that public disclosure is imminent.

 

 

Fedora: systemd-resolved Diskussion eskaliert

Wow, das habe ich nicht kommen sehen: Leonard Pöttering macht sich einen Feind fürs Leben, auf der Fedora-Devel Mailingliste 😐

Fedora: systemd-resolved Diskussion eskaliert

Das die Diskussion so schnell in einen Developerkrieg eskaliert, hätte ich nie für möglich gehalten:

„As we share the same employer, I encourage you to escalate my „derogatory behaviour“ to our magenement.

I did not read the rest of your email. I will not read or respond to further emails from you on mailing lists.“ (Paul Wouters, 29.9.2020 18:56 Uhr)

zu Deutsch:

„Da wir denselben Arbeitgeber haben, ermutige ich Sie, meine „abfälliges Verhalten“ unserem Arbeitgeber zu melden.

Den Rest Ihrer E-Mail habe ich nicht gelesen. Ich werde sie weder lesen, noch auf weitere E-Mails von Ihnen auf Mailinglisten antworten.“

Herr Pöttering schrieb dies vorher an die Mailingliste:

„“Custom“ is in the eye of the beholder. It appears to me you mean that in a derogatory way.

I mean, given that Ubuntu has been enabling systemd-resolved since quite some time by default I have the suspicion our codebase is more often deployed IRL than the ones you listed? I mean, maybe I am wrong, but it’s certainly not that this is exotic stuff as you imply.

I have the suspicion this is a territorial thing, no? It feels as if you believe that DNS clients that people wo are not core members of the DNS community are inherently a bad thing, and should go away, and leave the real work to the people who actually know how things work, right? I got that kind of behaviour once before when people told us to just leave service management to the real holy men of UNIX.“ (Leonard Pöttering, 29.9.2020 18:18 Uhr)

zu Deutsch:

„Kundenspezifisch“ liegt im Auge des Betrachters. Mir deucht, Sie meinen daß in abfälliger Weise.

Ich meine, angesichts der Tatsache, dass Ubuntu seit geraumer Zeit standardmäßig systemd-resolved aktiviert hat, habe ich den Verdacht daß unsere Codebasis häufiger IRL eingesetzt wird als die, die Sie aufgelistet haben? Ich meine, vielleicht irre ich mich, aber es ist sicher nicht so, dass dies so exotisch ist wie Sie andeuten.

Ich habe den Verdacht, dass dies eine territoriale Angelegenheit ist, nicht wahr? Es fühlt sich an, als ob Sie glauben, dass DNS-Clients, von Personen die keine Kernmitglieder der DNS-Kern-Gemeinschaft sind, von Natur aus eine schlechte Sache sind und verschwinden sollten, und überlassen Sie die eigentliche Arbeit den Menschen, die tatsächlich wissen, wie die Dinge funktionieren, richtig? Ich habe diese Art von Verhalten schon einmal erlebt, als man uns sagte „Überlassen Sie die Verwaltung der Dienste einfach den wahren heiligen Männern von UNIX“.“

Irgendwie kann ich beiden zustimmen, auf der einen Seite gibts extra eine teuer bezahlte Arbeitsgruppe bei der IETF, die Sachen entwicklen sollte, auf der anderen Seite kommen die nicht zu potte ( schreibt Pöttering einen Absatz später ). Trotzdem sehe ich das eher so, daß allein schon wegen fehlendem DNSSEC und dem Default Fallback zu Cloudflare und Google DNS-Servern, systemd-resolved nicht einfach so eingesetzt werden kann.

Angebot

Viele der Probleme, die resolved lösen soll, sind eherlich gesagt Luxusprobleme, die sich mit ein klein wenig Hirnschmalz lösen lassen. Bis auf ganz exotische Szenarien, wo jemand für alles, was er per Interface 1 erreichen kann, DNS 1und2  benutzen will und für Interface 2 dann DNS 3und4, reicht das. Wer ein echt komplexes Setup hat, mit VPN Tunneln durch VPN Tunnel der darf mir gern einen Leserbrief schicken und das mal darstellen. Dann schaue ich mir das gern mal an und gucke, ob das nicht einfacher geht. Herrn Pöttering habe ich auch um ein Beispiel angemailt, mal sehen ob eins kommt.