Linux: Surface Tablets und Laptops mit eigenem Kernel-Repo

„Du saga mal, Du hascht doch des Suuhrfaze, gibtsch da scho wos njeues pführ?“ hallte es aus dem mitfünfziger Herrn am Tisch gegenüber. Freundlich, aber bestimmt, machte Ihm mein Sitznachbar darauf aufmerksam, daß er kurz hinter Kiel wäre und folglich kaum zu verstehen sei. Dies schien den Herrn genauso wenig zu stören, wie der Umstand, daß mein Sitznachbar eher andigital veranlagt ist und es sich bei dem Gerät vielmehr um eine kurz Präsentationsleihgabe meinerseits handelte.

Nachdem die beiden Fischköpfe ( wir… vermutlich ) kurz getuschelt hatten, übersetzte eine junge Dame (Bezeichnung Anna-Luisa o7) für uns (daher auch die grobe Entschlüsselung oben) und es entstand eine schöne , wenn auch sehr kurze, Unterhaltung zum Thema: Linux auf einem Surface Pro 4.

Surface Tablets und Laptops mit eigenem Kernel-Repo

„Ja, da gibts was njeues.. ehm.. neues“ und für Euch schalte ich das Gespräch mal auf Allwissenden Erzähler um, sonst darf ich mich in Bayern gar nimmer sehen lassen. Also, Ja Leute, es gibt eine nicht mehr ganz taufrische Entwicklung, die teils sehr erfreulich, weil unheimlich praktisch ist, andererseits leider nicht so ganz funktioniert. Letzterer Teil wird derzeit noch untersucht.

Seit einige Monaten gibt es im Github einen eigenen Prebuild-Kernel für Arch, Debian und Fedora. Den richtet Ihr Euch so für Fedora ein:

  1. Das Repo hinzufügen:

sudo dnf config-manager --add-repo=https://pkg.surfacelinux.com/fedora/linux-surface.repo

2. Den Kernel  installieren:

sudo dnf install kernel-surface surface-firmware surface-secureboot
sudo dnf install --allowerasing libwacom-surface

3. Letztere Anweisung ist eher optional, falls man mit Wacom Probleme hat., was auch die Stifteingabe betrifft.

Surface rebooten, den neuen Kernel auswählen und jetzt kommt es drauf an, ob Ihr ein SP4/SB1 habt oder ein anderes Surfacegerät Euer eigen nennt, denn bei mir (SP4) bootet der Kernel zwar sauber, aber IPTS ist nicht da, was man allerdings für Touchbedienung braucht.  So bin ich kaum einen Schritt weiter als mit dem Kernel von Fedora selbst. Ein Problem an dem derzeit gearbeitet wird.

Und da ist auch schon die Lösung … ( sowas von genial den Artikel schon Tage im Voraus zu schreiben 😀 ) … dem mangelnden Touchsupport kann man so begegnen:

[root@surface]# rmmod ipts
[root@surface]# insmod /lib/modules/5.5.8-1.surface.fc30.x86_64/kernel/drivers/input/touchscreen/ipts/ipts.ko.xz singletouch=y

Was man dann so verewigt:

echo „options ipts singletouch=y“ > /etc/modprobe.d/ipts.conf

Man muß aber wissen, das dann der Stiftsupport abgeschaltet ist. Außerdem ist im 5.5er Kernel die Multitouch-Support komischerweise abgeschaltet, wer das braucht, muß den LTS Kernel 4.19 installieren. Ob das bei einem aktuellen Fedora 30/31/32 eine gute Idee ist, mag ich nicht entscheiden wollen. Allerdings hatte der 5.3er noch Multitouch dabei. Da frage ich mich jetzt, wieso das abgeschaltet wurde.

Weniger Energieverbrauch .. vielleicht

Eine andere Sache, die noch untersucht werden muß, ist der anscheinend geringere Stromverbrauch des 5.5.8 Kernels auf dem Surface Pro 4. zunächst sah es eher nach einem Batteryauslesebug aus, weil das Gerät lange auf 100% blieb, aber mittlerweile könnnte auch ein leichter Einspareffekt vorhanden sein. Ich hab das SP4 noch nicht lange genug im Referenzkernel laufen lassen, um da einen Vergleich zu haben. Ich schau nachher mal.

Kameras gehen immer noch nicht

Tja, schlechte Nachrichten für die NSA, die Kameras der Surface Pro 4+ funktionieren immer noch nicht unter Linux, was an sich jetzt schade für reguläre Kameranutzer ist. Dafür soll das Wifi jetzt im 5G Betrieb stabiler sein, was ja auch nicht ganz unpraktisch ist.

Die Sache mit dem Secure Boot

Nachdem ersten Boot, kommt im Bootprozess eine mördermäßig wichtige Einblendung, die einem bei der Installation auch mitgeteilt wird, allerdings steht im Installationshinweis, daß man, WENN MAN danach gefragt wird, ein Password eingeben soll um den signierten Kernel, bzw. dessen Signatur, ins Bios zu bekommen um dann Secure Boot nutzen können. Tja, was soll ich sagen, die Abfrage kam so nicht, denn dazu muß man während ein Timer runterzählt auf eine Taste drücken, sonst wird man auch nicht nach dem Passwort gefragt 🙂

Da ich da noch unsignierte Kernels zum Testen liegen habe, kann ich SecureBoot eh nicht einschalten, insofern ist mir das auch egal 😉 Wenn der neue Kernel natürlich dauerhaft funktioniert, dann kann man das später immer noch mit Hilfe des mokutil erledigen.

Der TypeCover Bug

Zwar prellt das TypeCover nicht mehr, aber dafür funktioniert es auch nicht mehr, wenn man es abzieht und wieder dran steckt. Was ein Problem darstellt, da man das Surface Pro 4 neu booten muß.

Ihr seht, da werden noch einige Fixe nötig werden, bis das stabil läuft.

Kernel <= 5.5.9 mit USB Bug

Besonders für alle Fans von  Surface Pro Linux-Tablets habe ich eine schlechte Nachricht im Bezug auf den Kernel 5.5.8: einige USB Geräte werden nur beim Booten erkannt, später aber nicht mehr.

Kernel <= 5.5.9 mit USB Bug

Die Liste der betroffenen Geräte dürfte bislang eher übersichtlich sein, da z.B. meine USB Maus oder mein USB Gigabit LAN Adapter  von dem Problem nicht betroffen sind. Über die Ursache ist bislang auch noch nichts bekannt, was aber nicht verwundert, da wir das erst heute Vormittag verifiziert bekommen haben.

Was ist denn überhaupt los?

Wenn man das Gerät mit Kernel 5.5.x bootet, wird das Microsoft eigene TypeCover, das ist die Tastatur und das Mauspad, welches auch als Deckel dient, korrekt als USB Device erkannt und funktioniert entsprechend. Allerdings nur so lange, bis jemand das TypeCover abzieht und wieder dransteckt. Dann funktioniert es nicht mehr.  Dabei ist es egal aus welcher Quelle man den Kernel hat, ob er direkt von Fedora oder selbst gebaut ist.

Wie wirkt sich das aus?

Die Ursache dafür, daß das TypeCover nach dem Einstecken an das Gerät nicht mehr funktioniert ist, daß es überhaupt nie vom USB BUS abgemeldet wurde. Das manifestiert sich darin, daß man mit „lsusb“ das Gerät noch sieht, auch wenn es bereits am anderen Ende der Wohnung liegt. Folglich wir es beim Einstecken nicht initialisiert und kann so seinen Job nicht tun.

Gegenmaßnahmen

Wie schnell so einn Satz wie „Derzeit hilft nur ein Reboot.“ obsolete wird. Der Einsatz von Kernel 5.5.9-200 (Upstreambuild) oder 5.4.19 bzw. jedes anderen 5.4er Kernel ohne Sicherheitslücke löst das Problem auch, weil es da nicht auftritt. Somit wurde auch indirekt bestätigt, daß es nur am Kernelcode liegt und nicht an der Installation oder irgendwelchen UDEV Tricks, die sind bei allen Kernels gleich, weswegen man die aus der Gleichung streichen kann.

Der Nachteil beim 5.4.x Kernel ist allerdings, daß er zu viel Strom verbraucht. Es wurden im Leerlauf 12 W gemessen, wo mit einem für Surface gebaute Kernel nur ~5 W verbraucht werden. Das sich das echt fies auf die Laufzeit auswirkt, dürfte jedem klar sein.

Die derzeit im Test befindliche 5.5.9-100 von Fedora löst das Problem noch NICHT.

Update ( 11:55 Uhr )

Wie das so mit Eilmeldungen ist, der Patch in 5.5.9-2 ist nicht stabil. Ein einem Boot funktioniert USB wieder, im anderen nicht. Ich halte Euch auf dem Laufenden, wenn ich was neues erfahre.

 

RDP: Remmina wird per Update brauchbar

Kleiner Nachbrenner zu RemoteDesktop mit XRDP & XFreeRDP . Vor einigen Tagen gab es ein Update von Remmina, womit es zum fast idealen RDP Clienten unter Linux wird.

Remmina wird per Update brauchbar

Vor einigen Tagen gab es ein Update von Remmina und da ich das schon im Test hatte, es aber mangels Funktion nicht einsetzbar war, habe ich Euch xFreeRDP empfohlen. Das ist auch weiterhin der Favorit, wenn  es verscriptet werden muß.am sieht im Hintegrund bereits den eingeloggten RDP Desktop und im Vordergrund die Basiseinstellungen von Remmina für diese Verbindung.

Remmina hat aber mit dem Update den Schritt auf meine Festplatte geschafft, weil es nämlich in seiner brauchbaren GUI-Oberfläche für jede Verbindung auch gleich einen SSH Tunnel anbietet. Da man auch einen Gatewayserver mit angeben kann, sind selbst komplexe RDP Setups kein größeres Problem mehr, wenn, ja wenn das Wörtchen Wenn nicht wäre.man sieht das Konfiguratiosnfenster von Remmiona das sich mit SSH Optionen beschäftigt.

Es gibt leider keine brauchbare, geschweige denn, belastbare Doku aus den man den Sinn dieser Optionen erfährt. Die Webseite zeigt zudem Screenshots, die schon lange überholt sind. Auch gibt es dort Anleitungen, die mangels der passenden Optionen nicht mehr klappen können, dafür sind Optionen ohne Contexthilfe, Mouseovertext oder sonstiger Hilfe vorhanden.

Das macht natürlich keinen so guten Eindruck. Auch wenn xFreeRDP  keine UI hat, stimmt hier wenigstens die Manpage.  Im Vollbildschirm ist gibt es eine schöne intelligente Leiste, die sich reinrollt, wenn man den Mauszeiger darüber bewegt. Die gleiche Funktionalität kennt man von TeamViewer oder der Windows-RDP Clienten. Daher kann ich das Programm jetzt zwar als sehr brauchbar einstufen, aber benutzerorientiert geht leider anders. Ich bin aber überzeugt, daß es auch ohne (aktuelle) Bedienungsanleitung gerade im Adminbereich viele Anhänger finden wird und schon hat(wie man so lesen kann). Der Verbindungsmanager ist halt unheimlich praktisch.

Neue Platte automatisch entschlüsseln lassen

Ich hab eine neue Platte im PC und die soll sich natürlich beim Hochfahren automatisch ins System integrieren, wenn ich das Passwort kenne. Leider klappt das mit den Automatiken nicht so ganz, daher müssen wir da kurz Hand anlegen.

Automatisch LUKS-Platten beim Boot einbinden

Zunächst brauchen wir mal eine mit LUKS verschlüsselte Platte. Um eine Platte mit LUKS zu verschlüsseln eignet sich das Laufwerketool. Die zu formatierende Partition auswählen und auf „Partition formatieren“ klicken:

man sieht die erste Formatierungsseite im LaufwerketoolIhr geht den neuen Namen für die Platte an, damit meldet die sich dann später im System, und wählt „Passwortgeschützter Datenträger (LUKS)“  aus. Ggf. habt Ihr die Wahl zwischen LUKS und LUKS2, aber F30 hat die noch nicht. Wenn ja, nehmt ruhig LUKS2.

Man sieht, wie das Passwort eingegeben wird.Ein ordentlich langes Passwort ist Pflicht. Danach dürft Ihr das noch einmal bestätigen und ein paar Sekunden später die Platte mit Hilfe des Lazy-Inits bereits bereit. „Lazy-Init“ meint, daß die Platte dort formatiert wird, wo Daten geschrieben werden sollen und nicht jetzt gleich die ganze Platte von Vorn bis Hinten formatiert wird. Das hätte nämlich bei 8TB 23 Stunden gedauert, da hatte ich wirklich keine Lust zu 😉

Die UUID ermitteln

Zwei Möglichkeiten eröffnen sich Euch: Ihr fragt das Laufwerkstool nach der UUID der neuen Platte ( Luks-Teil ) oder Ihr bemüht „blkid“ in der Konsole. Da wir diese eh gleich brauchen, bietet sich das an:

Erstmal ROOT werden:

$ su

dann suchen wir uns die UUID raus:

# blkid|grep sdd
/dev/sdd: UUID=“c16596bf-b40d-4c57-a46d-93b98d4bac47“ TYPE=“crypto_LUKS“

„sdd“ ist hier meine Platte. Eine UUID ist eine einmalige ID ( daher das zweite U ) die aufgrund eines einheitlichen Verfahrens ( das erste U ) erzeugt wird. Mehr müßt ihr darüber eigentlich nicht wissen.

Nun nehmen wir die UUID und tragen das passend in /etc/crypttab und /etc/fstab ein:

$ echo „/dev/mapper/luks-c16596bf-b40d-4c57-a46d-93b98d4bac47 /media/Huge ext4 defaults,x-systemd.device-timeout=0 1 2″ >>/etc/fstab

Da es sich um ein LUKS Laufwerk handelt und Devmapper das für uns managen wird, tragen wir den Devmapperpräfix und die UUID als Laufwerkspfad ein. „/media/Huge“ ist der Mountpoint, den Ihr bei Euch ggf. vorher noch anlegen müßt. Natürlich könnt Ihr auch einen anderen Pfad dafür nehmen, müßt Ihr wissen. Für alle Einsteiger: Der Mountpoint ist nichts weiter als ein leeres Verzeichnis. Das kann liegen wo Ihr wollt, aber /mnt/directory oder /media/directory  bieten sich an. Wichtig ist, daß da nichts anderes gemountet ist und der Pfad nicht in einem anderen Mountpoint ist.

Beispiel:

/media/Small
/media/Bigger
/media/Huge

ext4“ ist das Filesystem. Ihr werdet gemerkt haben, daß nach dem Formatieren der LUKS Partition ein weitere Partition unter der LUKS-Partition aufgetaucht ist. Da liegen Eure Daten dann wirklich drin. Das sieht so aus:

am sieht die Anzeige einer Luks-Partition gefolgt von der dadrin befindlichen normalen PartitionDiese Partition muß von Euch jetzt auch erst noch formatiert werden, dann natürlich passend zu dem Eintrag in der /etc/fstab, den wir gerade besprochen haben. Nehmt einfach Ext4, könnt Ihr praktisch nichts falsch machen. Wie Ihr sehen könnt, bekommt diese Partition eine eigene neue UUID. Aber das muß Euch jetzt nicht weiter belasten.

Damit die Platte jetzt auch beim Booten entschlüsselt wird und damit das Mounten/Einhängen des Laufwerks überhaupt erst möglich wird, tragt Ihr die UUID noch in die /etc/crypttab ein:

echo „luks-c16596bf-b40d-4c57-a46d-93b98d4bac47 UUID=c16596bf-b40d-4c57-a46d-93b98d4bac47 none“ >> /etc/crypttab

Das wars schon. Beim nächsten Booten ist die Platte dann sofort verfügbar.

„Keine Panik!“

Ok, eine freundliche Schriftart habe ich jetzt auf die Schnelle nicht zur Hand und großer geht es auch nicht, aber falls Ihr mal etwas vergessen oder Euch vertippt habt und Euer System nicht bootet.. KEINE PANIK!

Das löst sich ganz einfach:

1. den PC von einer USB-LIVE Disk booten.
2. Das Laufwerketool starten.
3. Eure Systempartition ggf. erst entschlüsseln und dann direkt im Tool mounten/einhängen.
4. TERMINAL öffnen
5. „su“ eingeben

6. „blkid“ eingeben
7. UUID in /etc/fstab und /etc/crypttab  vergleichen
8. Tippfehler beheben und Rechner neu booten.

99% aller Fehler in dem Bereich sind Vertipper oder man hat es schlicht und ergreifend nicht abgespeichert 🙂

CVE-2020-8597: Pre-Auth RCE in PPP

Ist Euch mal aufgefallen, daß über eine der dicksten Sicherheitslücken in 2020 so gut wie kein Wort verloren wird?

CVE-2020-8597: Pre-Auth RCE in PPP

Im Point-To-Point-Dienst wurde eine Lücke entdeckt, die es erlaubt Code auszuführen, noch bevor man sich autorisieren muß. Die Brisanz an der Sache ist, daß nicht nur die Server betroffen sind, sondern auch die Clienten. Eingesetzt wird das u.a. bei VPN Systemen.

Was mich an der Sache ein bisschen ärgert ist, daß seit 2 Wochen das Update vom ppp bei Fedora im Bodhi hängt, weil mal wieder keiner zum Testen Zeit & Lust hatte, was mir sehr bekannt vorkommt. Davon mal abgesehen, wurde der aktuelle Chef vom Fedoraprojekt direkt nach entdecken der Lücke über die Brisanz, den Entdecker und die verifizierende Quelle informiert, keine 8 Stunden nach den ersten Gerüchten. Ich weiß das, weil ich das gemacht habe, mit dem Hinweis es an die Security von RH, PPP etc. zu  eskalieren.

Damit mußte eigentlich allen Beteiligten klar sein, daß es sich um ein Critupdate handelt. Kritisch ist das nämlich, weil viele VPN Techniken, außer SSH, auf den ppp setzen und damit eine echt große Angriffsfläche gegeben ist. Die Lücke ist so krass, daß die sogar osübergreifend existiert. Das erlebt man ja auch nicht jeden Tag.

Der, sagen wir mal schweigsame, Umgang mit der Lücke, auch in den Medien führt übrigens dazu, daß Kunden diverser Produkte die den ppp kommerziell einsetzen nicht mal wissen, daß es diese Lücke gibt, was dazu führt, daß es keinen Druck bei den Herstellern gibt. Ich befürchte sogar fast, daß die nicht mal wissen, das es die Lücke gibt, weil das erst heute, 2 Wochen nach bekanntwerden,  über FullDisclosure gelaufen ist und somit auch erst jetzt die Runde macht.

Pro-Linux.de ist übrigens eine der wenigen Seiten in Deutschland, die überhaupt über diesen Bug berichtet haben, aber auch mehr, weil es ein automatisches Advisory von Debian gab und weniger, weil daß jemandem aufgefallen ist. Für eine Pre-Auth RCE mit Eskalation zu Root ist das alles eine sehr seltsame Sache. The Hacker News hat vor 2 Tagen darüber berichtet, aber das wars dann schon. Golem oder Heise vermisst man mal wieder, dabei wäre das ein gefundenes Fressen für die Medien, weil es Millionen betroffener Clients und Server gibt.

Wenn Android hustet, …

…, wo niemand genau weiß, ob jemand wirklich davon betroffen ist, da raschelt es gleich im Blätterwald, aber wenn die Sicherheit von Millionen Hosts in Gefahr ist, dann bleibt alles ruhig?

Dem einen oder anderen stellt sich jetzt vermutlich die Frage, wieso habe ich das nicht gleich im Blog gepostet als ich davon erfuhr? Ich wollte meiner Distro einen kleinen Vorsprung geben, damit der Patch ausgerollt wird, bevor die Masse der Blackhats das mitbekommt. Nachdem Fefe das in seinem Blog rausgehauen hatte, konnte man zu dem annehmen, daß es im Blätterwald sehr schnell die Runde machen würde, was ja dann überraschenderweise nicht passiert ist.

Ihr merkt, bei dieser Lücke ist einiges anders als sonst. Ich frage mir nur gerade, was eigentlich die Lektion ist, die wir daraus lernen sollten: „trotz wager Infos die Posaune rausholen und sofort berichten“ oder „doch abwarten bis es mehr Infos gibt und so riskieren, daß keiner was meldet“? Ich muß gestehen, da bin ich auch überfragt. So etwas wie beim ppp darf sich jedenfalls nicht wiederholen.