CleanPress

Kategorie: News

  • Aktuelle Entwicklungen bei Fedora Workstation

    Screenshot: FThommes

     

    In der Fedora-Experimentierküche brodeln zu jeder Zeit interessante Entwicklungen. Red-Hat-Mitarbeiter Christian Schaller berichtet in unregelmäßigen Abständen über solche Entwicklungen, die dann in absehbarer Zeit in Fedora Workstation verfügbar sein werden. Jetzt bietet die kürzlich zu Ende gegangene GNOME-Entwicklerkonferenz GUADEC den Anlass für Schaller, einen neuen Bericht zu veröffentlichen.

    Wayland im Hintergrund

    Bei den meisten derzeitigen Projekten steht Wayland im Hintergrund. So etwa auch bei Remote Desktop und Desktop-Sharing. Hier stellen Unterschiede von X11 zum von Fedora Workstation seit einigen Veröffentlichungen als Standard eingesetzten Wayland-Protokoll die Entwickler vor neue Herausforderungen.

    Entfernte Desktops laden

    Jonas Ådahl arbeitet derzeit an Remote-Desktop für die GNOME-Shell. Die für Ende Oktober erwartete Veröffentlichung von Fedora 29 Workstation soll eine VNC-basierte Implementierung des Remote-Desktop bieten, weitere Protokolle wie etwa Spice sollen folgen. VNC ist zwar ziemlich veraltet, ist trotzdem noch recht weit verbreitet und anspruchslos im Einsatz. Um die Wayland-Sitzung über VNC zu teilen kommt das Multimedia-Framework PipeWire zum Einsatz, das vom GStreamer-Pionier Wim Taymans entwickelt wird.

    Desktop-Sharing per WebRTC

    Jan Grulich, Tomas Popela und Eike Rathke arbeiten seit geraumer Zeit am Desktop-Sharing unter Wayland mit Firefox und Chromium unter Zuhilfenahme von WebRTC. Auch hier spielt PipeWire das Bindeglied, indem die Browser jeweils ein PipeWire-Backend erhalten. Eine gepatchte Firefox-Version steht bereits seit einiger Zeit zum Testen für Fedora 28 und Fedora Rawhide bereit.

    PipeWire

    Auf der GUADEC 2017 hielt Entwickler Wim Taymans einen Vortrag über die Ideen hinter und den Entwicklungsstand von PipeWire. Hier wird unter anderem beständig an der Nachbildung der Funktionalität des professionellen Audio-Servers Jack gearbeitet. Die Player Totem und Rhythmbox können zum Abspielen von Audio über PipeWire mit dem PulseAudio-GStreamer-Plugin genutzt werden, nachdem ein Ersatz für die libpulse.so implementiert wurde.

    Im Herbst wird ein PipeWire und Linux Audio Hackfest stattfinden, bei dem die Teams von  PipeWire, GStreamer, Totem, GNOME Control Center, PulseAudio und Jack über die weitere Entwicklung von PipeWire diskutieren.

    GNOME Builder im Container

    GNOME Builder, die integrierte Entwicklungsumgebung, die seit einiger Zeit in den GNOME-Desktop integriert ist, wird maßgeblich von Christian Hergert entwickelt. Die derzeitige Entwicklung geht in Richtung Unterstützung für die Entwicklung hin zu Embedded-Geräten wie dem kommenden Linux-Smartphone Purism 5. Christian erwähnte zudem in seinem GUADEC-Vortrag, dass Builder wahrscheinlich die erste »Container Native IDE«  der Welt ist, indem es einerseits mit dem Ziel entwickelt wird, als Flatpak verteilt zu werden, als auch, Flatpaks als primäres Ausgabeformat zu erstellen.

  • OwnCloud 10.0.9 erhöht die Flexibilität mit »Pending Shares«

    OwnCloud 10.0.9
    Bild: ownCloud2-Logo | Quelle: Wikimedia | Lizenz: AGPL

     

    OwnCloud, eine Anwendung zum Speichern, Synchronisieren und Austauschen von Daten auf einem eigenen Server hat Version 10.0.9 vorgestellt. Die neue Version bringt zahlreiche Verbesserungen, erhöht die Flexibilität und verbessert die Passwort-Richtlinien.

    Mehr Kontrolle und Flexibilität

    OwnCloud Server 10.0.9 führt unter anderem eine neue Funktion ein, um und den Benutzern mehr Kontrolle über eingehende Freigaben zu geben. Bisher wurden freigegebene Inhalte unangekündigt in der Dateihierarchie des empfangenden Benutzers angezeigt und die Clients begannen mit der Synchronisierung. Eingehende Freigaben können mit der Einführung der Funktion »Pending Shares« nun einen schwebenden Zustand haben, der dem Anwender die Möglichkeit bietet, anstehende Freigaben komplett oder selektiv anzunehmen oder abzulehnen.

    Bessere Übersicht

    Neben der Funktion »Pending Shares« bietet der OwnCloud-Server nun auch die Möglichkeit, akzeptierte, ausstehende und abgelehnte Freigaben anzuzeigen. Mithilfe des Filters Mit Dir geteilt in der Seitenleiste der Dateiansicht können Benutzer nun alle eingehenden Freigaben mit ihren jeweiligen Zuständen auflisten und einfach zwischen den Zuständen wechseln. Diese Verbesserung ermöglicht es nicht nur, zuvor abgelehnte Freigaben nachträglich zu akzeptieren, sondern auch zuvor nicht freigegebende Shares wiederherzustellen, ohne dass der Eigentümer sie erneut freigeben muss.

    Passwortrichtlinie für alle

    Eine Funktion, die bisher zahlenden Kunden vorbehalten war, ist mit Owncloud 10.0.9 nun auch in der Community-Version verfügbar. Es handelt sich dabei um die »Password Policy Extension«, eine erweiterte Passwort-Richtlinie, die nun unter der GPLv2 steht.  Die neue Richtlinie unterstützt nun Passwort-Verfalls- und Verlaufsrichtlinien für alle Benutzerkonten. So kann ein Administrator unter anderem festlegen, wie oft Anwender ein Passwort erneuern müssen und kann bereits benutzte Passwörter von der Verwendung ausschließen.

    Neuer Ansatz beim Object Storage

    Ebenfalls für die Community freigegeben wurde S3 Object Storage. Mit der Integration des S3-Protokolls erhalten alle Anwender von Owncloud die Möglichkeit, Object-Speicherung zu verwenden. Gleichzeitig wird die Unterstützung des OpenStack-Swift-Protokolls zur verteilten Speicherung von Daten als veraltet eingestuft.

    OwnCloud wurde 2010 von KDE-Entwickler Frank Karlitschek entwickelt, um Daten unter eigener Kontrolle vorhalten, synchrionisieren und austauschen zu können. Im Jahr 2016 verließ Karlitschek mit der Mehrzahl der Entwickler das Unternehmen und gründete den Konkurrenten Nextcloud. Hauptunterscheidungsmerkmal ist, dass Nextcloud alle Entwicklungen von vornherein der Community frei zur Verfügung stellt.

    Eine Übersicht über sämtliche Änderungen zu Owncloud 10.0.9 sind in den Release Notes  und in Changelog zu finden. OwnCloud 10.0.9 steht zum Download auf der Webseite des Herstellers zur Verfügung.

  • Ein Vierteljahrhundert Slackware

    Slackware
    Bild: Slackware 14.1 | Quelle: Phillip Lacroix | Lizenz: GPL

    Slackware ist ein Vierteljahrhundert alt und damit die älteste noch aktive Linux-Distribution. Gestern vor 25 Jahren kündigte Patrick J. Volkerding, Gründer von Slackware, in einem Usenet-Posting die Version 1.00 der Distribution an. Diese basierte damals auf Torvalds Kernel 0.99.10 und stand mit einem Umfang von insgesamt 24 Disketten per FTP zum Download bereit.

    Knapp vor Debian

    Eigentlich wollte Volkerding keine Linux-Distribution ins Leben rufen, sondern Installation und Konfiguration der Distribution Softlanding Linux System (SLS) verbessern, die bereits ein Jahr zuvor von Peter MacDonald veröffentlicht worden war. Als er damit kein Glück hatte, veröffentlichte er SLS mit seinen Änderungen als Slackware. Ian Murdock, ein weiterer unzufriedener SLS-Nutzer, startete wenig später Debian. Slackware bildete unter anderem die Grundlage für die ersten Veröffentlichungen von SuSE Linux.

    Alleinherrscher Volkerding

    Volkerding bestimmte damals wie heute als Ein-Mann-Show die Geschicke von Slackware, trifft alle Entscheidungen und ist sehr aktiv in der Slackware-Community. Er lehnt die Distribution möglichst nah an Unix an. So gibt es bei Slack, wie die Distribution auch genannt wird, keine distributionsspezifischen Werkzeuge für die Konfiguration. Die Webseite postuliert »Benutzerfreundlichkeit und Stabilität«  als Ziele der Distribution. Dabei sollte Benutzerfreundlichkeit im Sinne von Einfachheit verstanden werden, denn Slack besitzt keinen grafischen Installer und der Paketmanager kennt keine automatische Auflösung von Abhängigkeiten.

    Einfach und zuverlässig

    Das stört die Slacker, wie die Fans der Distribution genannt werden, wenig. Aber es stellt in der heutigen Zeit das geistig verwandte Arch Linux in ein anderes Licht, bedenkt man dessen Ruf als schwierig. Slackware hat keinen öffentlichen Bug-Tracker, kein Code-Repository und keine festgelegte Einbindung der Community.

    Slack-Derivate

    Volkerding veröffentlicht den Rolling-Release-Zweig  current, wann immer er es für angebracht hält und wird dabei von ein paar wenigen Helfern unterstützt. Wichtig ist für viele Slacker, dass Volkerding sich bisher erfolgreich gegen die Integration von Systemd wehren konnte. Slackware hat unter anderem Derivate wie Absolute Linux, Frugalware, Slax, Salix OS und Porteus hervorgebracht.

    Die aktuelle Veröffentlichung ist Slackware 14.2, das neben Kernel 4.4.14 und X11 R7.7 als Desktop sowohl Xfce 4.12.1 als auch KDE 4.14.21 anbietet und Installation und Booten per UEFI unterstützt. Die anhaltende Beliebtheit von Slackware bei den Fans beruht vermutlich darauf, dass Slack dem Fortschritt nicht abgeneigt ist, aber nicht jedem Trend hinterherrennt.

  • Ubuntu Snaps – das Sandbox-Modell

    Ubuntu Snaps
    Bild: Sandbox | Quelle: Simon Law Lizenz: CC BY-SA 2.0

     

     

    Canonical hat mit Ubuntu Snaps ein Paketformat entwickelt, das seine Vorteile hauptsächlich im Internet der Dinge und in eingebetteten Systemen ausspielen soll, aber auch auf dem Desktop zunehmend Verbreitung findet. Durch seine plattform-unabhängige Eigenständigkeit erlaubt es beispielsweise das Testen von aktuellen Versionen von Software, die unter der verwendeten Distribution noch nicht verfügbar sind. Entwickler können damit ihre Software in ein Paket stecken, das auf allen Plattformen lauffähig ist, die das Snap-Format unterstützen.

    Ubuntu Snaps im Sandkasten

    Aus Sicherheitsgründen arbeiten Snaps, wie auch das alternative Flatpak-Format in sogenannten Sandboxen. Das bedeutet, die Anwendung ist eingesperrt und erhält nur die notwendigen Zugriffe auf das Gast-System. Aus Entwicklersicht gibt es drei Stufen der Beschränkung, die mit Devmode, Classic und Strict betitelt sind. Was der Endanwender erhält, wenn er ein Snap aus der Abteilung Stable des Ubuntu-Snap-Store installiert, entspricht immer Strict.

    Strict-Mode

    Snaps, die nach dem Strict-Mode erstellt wurden können ohne manuelle Überprüfung in den Store hochgeladen werden. Das Strict-Modell beschränkt eine Applikation mittels Sicherheitsfunktionen des Kernels. Werden hier keine Ausnahmen definiert, hat die App keinerlei Zugriff auf das System. Diese Ausnahmen heißen Interfaces und stellen Schnittstellen für den Zugriff der App auf definierte Bereiche des Gast-Systems dar.

    Devmode

    Um funktionierende Ubuntu Snaps zu erstellen, in denen diese Schnittstellen der kasernierten App die nötigen Zugriffe erlauben, steht Entwicklern der Devmode zur Verfügung. Mit dieser Einstellung erstellte Snaps sind zunächst nicht in ihrem Zugriff beschnitten, der Entwickler kann also beim Testen Schnittstellen suchen, die den nötigen Zugriff erlauben und den Rest einschränken. Wird eine noch nicht definierte Schnittstelle benötigt, kann der Entwickler diese per Bugreport anregen. Snaps im Devmode können lediglich in den Kanälen Edge und Beta veröffentlicht werden und stehen somit zur Durchsicht und Qualitätssicherung bereit.

    Classic-Mode

    Das Modell Classic bietet der Anwendung in einem Snap alle Zugriffe auf das System, die auch eine Anwendung ohne Snap-Beschränkung hat. Dieser Modus bietet Entwicklern die Möglichkeit, Anwendungen als Snap auszuliefern, die noch nicht als Schnittstelle definierte Zugriffe benötigen. Stehen diese Schnittstellen später zur Verfügung, kann der Entwickler auf Strict wechseln.

    Snaps nach dem Classic-Modell werden manuell überprüft bevor sie im Stable-Channel des Ubuntu-Snap-Store veröffentlicht werden. Sie dürfen allerdings keine Verwendung im Ubuntu-Core finden. Anwender haben bei der Installation eines Snap die Möglichkeit, das vom Entwickler vorgegebene Level an Beschränkung zu übergehen, indem sie etwa den Schalter -classic verwenden. Das ist allerdings nicht ratsam, denn es entfernt alle definierten Interfaces und erlaubt der Anwendung ungehinderten Zugriff.

    Mehr zu diesem Thema vermitteln ein Blogeintrag von Alan Pope, nochmals vertieft in der Snapcraft-Dokumentation.

     

  • Debian GNU/Linux 9.5 erschienen

    Debian GNU/Linux 9.5 erschienen

    Debian 9.5
    Screenshot: ft

     

    Debian 9.0 »Stretch« erschien am 16.6. 2017 und erhielt jetzt mit Debian 9.5 sein fünftes Punkt-Update. Debian 9.4 erschien Mitte März. Wie üblich bei Debian werden mit den Punkt-Releases über die Laufzeit einer Veröffentlichung Sicherheitsupdates verteilt und Fehler in Paketen behoben, wenn dies möglich ist, ohne Regressionen hervorzurufen.

    Neuer Intel-Microcode

    Debian 9.5 ist vergleichsweise groß ausgefallen und bringt 100 Sicherheits-Updates und 91 behobene Fehler in Paketen. Unter anderem erhält Debian 9.5   »Stretch«  damit einen neuen Intel-Microcode mit der Versionsnummer 3.20180425.1~deb9u1, der auch Code zum Schutz gegen die Prozessor-Lücke Spectre v2 enthält. Neben der Auslieferung des neuen Kernel 4.9.110 und einem Update für den  Debian-Installer wurden auch Pakete wie apache2, base-files, clamav, dpkg, reportbug und systemd von Fehlern befreit.

    Sicherheit verbessert

    Bei der Verbesserung der Sicherheit erhielt Firefox-ESR insgesamt sechs Security-Updates, unter anderem gefolgt von Xen mit vier und Thunderbird mit zwei Vorfällen. Weiterhin betroffen war auch hier der Webserver Apache2 ebenso wie WordPress Drupal7, Gnupg1 und 2. Alle Sicherheits-Updates wurden bereits in einem »Debian Security Advisory« (DSA) beschrieben.

    Bitte aktualisieren

    Insgesamt fassen die Debian-Punkt-Releases die Sicherheitsupdates und Fehlerkorrekturen seit dem jeweils letzten Punkt-Release zusammen. Anwender, die ihr System regelmäßig aktualisieren, haben die meisten Sicherheits-Aktualisierungen bereits erhalten. Ein Debian-Punkt-Release erfordert keine Neuinstallation des Systems. Die neuen Pakete können über die Paketverwaltung aktualisiert werden.

    Frische Images

    Erste aktualisierte Images für Anwender, die trotzdem eine neue Installation vornehmen möchten stehen auf den Download-Servern zur Verfügung, weitere werden in den nächsten Tagen folgen. Bis im nächsten Jahr die nächste Debian-Veröffentlichung Debian 10 »Buster« erscheint, werden vermutlich eine weitere Handvoll Punkt-Releases folgen.

  • Guido van Rossum: Eine Ära geht zu Ende

    Guido van Rossum
    Bild: Guido van Rossum | Quelle Daniel Stroud | Lizenz: CC BY-SA 4.0
    Guido van Rossum, der Autor der Programmiersprache Python, ist überraschend von der Projektleitung zurückgetreten. Das teilte er seinen Kollegen in einer Mail an die Python-Entwicklerliste mit. Bis zu seinem Rücktritt galt er als Benevolent Dictator For Life (BDFL), als wohlwollender Diktator auf Lebenszeit.

    Fast 30 Jahre

    Der Niederländer van Rossum lenkte die Geschicke von Python, der laut Umfragen beliebtesten Programmiersprache der Welt, seit 1989 für fast 30 Jahre, bevor er nun das Zepter niederlegte. Er verlässt das Projekt nicht endgültig, sondern verbleibt nach eigener Aussage noch eine Weile als »gewöhnlicher Kern-Entwickler« und als Mentor für Neueinsteiger in die Entwicklung. Mit den Entscheidungsprozessen innerhalb des Projekts will er aber nichts mehr zu tun haben. Ausschlaggebend für seinen Weggang war nach seinen Worten das heftige Ringen um eine Entscheidung über PEP 572, einen Erweiterungsvorschlag, der letztlich durch ein Machtwort von van Rossum entschieden werden musste.

    »So what are you all going to do? Create a democracy? Anarchy? A dictatorship? A federation?« – Guido van Rossum

    Der 62-jährige van Rossum führt in seiner Mail unter anderem auch gesundheitliche Probleme an, aber aus einigen Aussagen lässt sich klar herauslesen, dass Rossum müde ist, mit den Kollegen über  Entscheidungen zu ringen und dass es Konflikte im Führungsgremium gibt. Er bestimmt keinen Nachfolger und überlässt seine Hauptentwickler sich selbst. Er sieht keine Probleme in den täglich zu treffenden Entscheidungen, das könne weiter gehen wie bisher.

    Konfliktpotenzial erkannt

    Probleme sieht van Rossum eher darin, wie künftig die sogenannten Python Enhancement Proposals (PEPs), also die Vorschläge zur Weiterentwicklung von Python, und die Bestallung neuer Hauptentwickler entschieden werden. Hier sieht van Rossum Konfliktpotenzial. Er erinnerte die Entwickler daran, dass Python einen »Community Code of Conduct« (CoC) hat, und fügte hinzu: »Wenn Euch dieses Dokument nicht gefällt, besteht Eure einzige Möglichkeit darin, diese Gruppe freiwillig zu verlassen«.

    Suche nach neuem Führungsmodell

    Während die Entwickler hoffen, van Rossums Weggang sei lediglich vorübergehend, so schauen sie sich gleichzeitig bei anderen Open-Source-Projekten nach einem möglichen neuen Führungsmodell um. Ein mögliches Szenario dabei ist, eine Dreierspitze zur Führung des Projekts einzusetzen. Es bleibt zu hoffen, dass Python seine Führungskrise schnell überwindet undabei keinen Schaden nimmt. Van Rossum arbeitete von 2005 bis 2012 bei Google, wo er die Hälfte seiner Zeit in die Weiterentwicklung von Python stecken konnnte. Seit 2013 arbeitet er bei Dropbox.

  • Chrome 67 verstärkt die Sicherheit mit Seiten-Isolierung

    Chrome 67
    Bild: google_chrome | Quelle jibunkaiwai | Lizenz: CC BY 2.0

     

    Mit Chrome 67 dreht Google weiter an der Sicherheitsschraube. Das neueste Feature im Kampf gegen Spectre & Co. heißt Site Isolation, zu deutsch Seiten-Isolierung. Mit der Sicherheit erhöht sich allerdings auch der RAM-Bedarf des Browsers.

    Verschärfte Trennung

    Mit Site Isolation verschärft Google die Trennung von Inhalten im Browser. Galt bisher die Maxime, dass jeder Tab in einem eigenen Prozess läuft, so verfeinert Google nun diese Aufteilung weiter. Mit der bisherigen Lösung liefen etwa Cross-Site-Iframes oder -Pop-Ups im gleichen Prozess wie die Seite, die sie erzeugt hatte. Das erlaubte einem erfolgreichen Spectre-Angriff unter Umständen, Daten wie unter anderem Cookies oder Passwörter anderer Frames oder Pop-ups zu lesen.

    Spectre-Angriffe erschweren

    An Site Isolation arbeitete Google schon lange, bevor die Spectre-Angriffe Furore machten. Dabei geht es um eine einschneidende Änderung der Chrome-Architektur, die jeden Rendering-Prozess auf Dokumente von einer einzigen Seite beschränkt. Dies bedeutet, dass alle Navigation zu Cross-Site-Inhalten den jeweiligen Tab zum Wechseln der Prozesse veranlasst. Es bedeutet auch, dass alle Cross-Site-Iframes in einen anderen Prozess als ihr übergeordnetes Frame gesetzt werden, indem out-of-process iframes verwendet werden.

    Site Isolation für (fast) alle

    Mit Chrome 67 ist Site Isolation für 99 Prozent der Nutzer auf allen Betriebssystemen aktiviert, das verbleibende eine Prozent dient als Kontrollgruppe. Mit der Aktivierung reduziert sich die Datenmenge, die ein Angreifer stehlen könnte, und »reduziert die Bedrohung durch Spectre erheblich«, so Google.

    Kehrseite der Medaille

    Google plant, die Site Isolation auf Chrome für Android auszudehnen und arbeitet an der Lösung bekannter Probleme. Mit Chrome 68 kann die Seiten-Isolierung sowohl manuell auf dem Handy über ein Flag als auch über Unternehmensrichtlinien aktiviert werden. Wie so oft, hat aber auch diese Verbesserung einen Pferdefuß: Dadurch, dass mehr Rendering-Prozesse erzeugt werden, erhöht sich der RAM-Verbrauch des beliebtesten Browsers weiter. Google-Entwickler Charlie Reis führte das im Sicherheitsblog des Unternehmens aus:

    Site Isolation führt dazu, dass Chrome mehr Rendering-Prozesse erstellt, was mit Leistungseinbußen verbunden ist: Auf der positiven Seite ist jeder Rendering-Prozess kleiner, kurzlebiger und hat intern weniger Konkurrenz, aber es gibt aufgrund der größeren Anzahl von Prozessen etwa 10-13 Prozent Gesamtspeicher-Overhead in realen Workloads. Unser Team arbeitet weiterhin hart daran, dieses Verhalten zu optimieren, um Chrome schnell und sicher zu halten.

  • Ubuntu-Fehler: Sperrbildschirm kann umgangen werden

    Ubuntu-Fehler
    Bild: Security | Quelle GotCredit | Lizenz: CC BY-2.0

     

    Hacker können Zugriff auf laufende Anwendungen auf einem Ubuntu-Rechner erhalten, wenn Sie physischen Zugriff auf dessen Festplatte haben. Dieser bereits am 18. Juni gemeldete und erst  jetzt bekannt gewordene Ubuntu-Fehler betrifft alle Versionen seit Ubuntu 14.04 LTS »Trusty Tahr«.

    Vermutlich sind aber auch die Derivate der Ubuntu-Familie (bestätigt für 18.04 MATE) als auch Ableger wie Linux Mint und andere betroffen. Dabei besteht Zugriff auf offene Anwendungen des Anwenders, bevor dieser das Gerät in den Ruhemodus schickt.

    Kritischer Ubuntu-Fehler

    Wenn der Angreifer die Festplatte, auf der sich die Installation befindet, während des Ruhemodus (suspend) entfernt und dann das Gerät aufweckt, gibt es mehrere Möglichkeiten: Der Sperrbildschirm erscheint und die Eingabe eines beliebigen Passworts erlaubt den Zugriff. Wenn das beliebige Passwort nicht angenommen wird, kann der Ausschaltknopf der Hardware betätigt und dadurch der Zugriff erreicht werden. Bleibt der Bildschirm dunkel, kann der Vorgang, beginnend mit dem Ruhemodus des Rechners wiederholt werden.

    Die erste Stellungname eines Canonical-Security-Ingenieurs liest sich nicht gerade beruhigend:

    [su_quote style=“modern-light“ cite=“Marc Deslauriers“]Es ist unwahrscheinlich, dass wir dies beheben werden, da ein Angreifer mit einem physischen Zugriff einfach direkt auf die Festplatte zugreifen oder das Passwort auf der Festplatte ersetzen und den Computer entsperren kann.[/su_quote]

    Auch wenn dies so richtig ist, das Entfernen der Festplatte eines Rechners erfordert lediglich mechanisches Geschick und kein Wissen wie man das Passwort ersetzt. Es ist ein einfach klingender Hack und er funktioniert, indem er einen Fehler in der Art und Weise ausnutzt, wie das System Daten speichert, wenn Ubuntu im Ruhezustand ist.

    Ein weiterer in diesem Zusammenhang aufgetauchter Fehler erlaubt manchmal das Umgehen des Sperrbildschirms durch Anschließen eines HDMI-Monitors, sobald der Sperrbildschirm auftaucht.

    AMD-Microcode zurückgezogen

    Erst gestern wurde ein anderes Sicherheitsproblem bei Ubuntu 14.04 LTS »Trusty Tahr« beseitigt, indem der vorherige unsichere Zustand wieder hergestellt wurde. Der am 20. Juni ausgelieferte AMD-Microcode musste zurückgezogen werden, da er durch eine Regression vereinzelt den Bootvorgang von Rechnern unterbrach und diese somit nutzlos machte.

    Der AMD-Microcode sollte eigentlich den Auswirkungen der Anfang Januar bekannt gewordenen Spectre-Lücke (CVE-2017-5715) entgegenzuwirken. Nun zog Canonical den Microcode zurück, indem das Paket amd64-microcode 3.20180524.1~ubuntu0.14.04.2+really20130710.1 an seine Stelle rückte.

  • Plasma-Desktop-Verbesserungen im Juni

    Plasma-Desktop-Verbesserungen im Juni

    Plasma Desktop
    Screenshot

    Im wöchentlichen Rhythmus veröffentlicht KDE-Entwickler Nate Graham unter dem Titel Usability and Productivity die Arbeit des Teams bei der Verbesserung des Plasma-Desktops. In den vergangenen Wochen gab es wieder einige interessante Einträge.

    Discover verbessert

    Das begann mit einer Änderung bei Plasmas Software-Installer Discover. Die Anwendung kann jetzt auf Wunsch anzeigen, welche Abhängigkeiten die Installation eines Pakets nach sich ziehen würde. Bei System-Updates zeigt Discover an, welche Pakete entfernt oder ersetzt werden sollen. Es verhindert künftig zudem, dass der Anwender sich ohne Warnung abmelden kann, während Discover noch Pakete installiert. Das führte bisweilen zu inkonsitentem Verhalten nach Wiederanmelden.

    Kontroverse Änderung zurückgenommen

    Für Aufregung hatte im letzten Jahr eine Änderung gesorgt, die der ehemalige KWin-Entwickler Martin Flöser eingeführt hatte. Er verhinderte damit, dass Anwendungen wie Dolphin, Kwrite oder Kate als Root gestartet werden konnten. Viele Anwender sahen dies als unter Linux unzulässige Bevormundung an. Jetzt hat Nate Graham diese Beschränkung wieder aufgehoben, zuminmdest bei Dolphin aber eine Warnung eingefügt.

    [su_slider source=“media: 5648,5652,5650,5656,5655,5654,5653″ limit=“12″ link=“lightbox“ width=“960″ height=“960″ autoplay=“0″ speed=“0″]

    Dolphin kann teilen

    Dolphin erhält zudem die beiden neuen Kontextmenüeinträge Sort by und View Mode. Wird künftig eine Datei in Dolphin umbenannt und der neue Name liegt außerhalb des Blickfelds, scrollt Dolphin automatisch dorthin. Eine weitere Verbesserung erhält Dolphin im Kontextmenü. Wie Spectacle und Okular erhält der Dateimanager einen Share-Eintrag zum Teilen mit verschiedenen Diensten.

    Bildwerkzeuge lernen dazu

    Beim Bildbetrachter Gwenview können Bilder nun per Drag&Drop angezeigt werden. Zudem können angezeigte Bilder mit der Maus in andere Anwendungen gezogen werden. Das Screenshot-Tool Spectacle kann jetzt Bilder via  KDE Connect an Smartphones übergeben. Per Spectacle mit Imgur geteilte Bilder senden den entsprechenden Link nun zurück in die Zwischenablage.

    Alle erwähnten Änderungen fließen in KDE Applications 18.08.0 ein, das am 16. August veröffentlicht werden soll. Für Plasma 5.14 wurde in den Systemeinstellungen zudem das Libinput-Backend für Maus und Touchpad optisch und funktional überarbeitet.

     

  • Einbruch bei Gentoo durch Achtlosigkeit ermöglicht

    Einbruch bei Gentoo
    Photo by Anas Alshanti on Unsplash

     

    Die Analyse des Einbruchs und der Übernahme des GitHub-Repositories der Linux-Distribution Gentoo ist abgeschlossen. Aus dem jetzt vorliegenden schriftlichen Report lassen sich zwei Kernaussagen ableiten.

    Vorbildliche Reaktion

    Zum einen haben die Entwickler vorbildlich reagiert und sind sofort nach der Entdeckung an die Öffentlichkeit gegangen. Zweitens wurde der Einbruch durch ein kompromittiertes Passwort auf einer anderen Webseite erst ermöglicht. Wie die Entwickler feststellten, konnte das Passwort für den Hack von dem kompromittierten Passwort abgeleitet werden. Einer der Entwickler verwendete ähnliche Passwörter auf verschiedenen Webseiten und Diensten.

    Drei Repositories betroffen

    Der oder die Einbrecher hatten nach dem Eindringen zunächst alle legitimen Accounts entfernt und dann versucht, durch das Hinzufügen von rm -rf-Kommandos in verschiedenen Repositories Daten auf den Rechnern der Nutzer zu löschen, die per git pull diese Repositories auf ihre Rechner ziehen. An dieser Stelle waren allerdings Sicherheitsmaßnahmen eingebaut, die das Ausführen dieser Befehle verhinderten. Betroffen von den Änderungen der Einbrecher waren die Repositories gentoo/gentoo, gentoo/musl und gentoo/systemd. Kopien dieser Repositorien aus dem betroffenen Zeitraum sollten auf keinen Fall genutzt werden.

    Schwachstellen identifiziert

    Die Analyse hat einige Schwachstellen in der Handhabung der GitHub-Repositories seitens der Gentoo-Entwickler aufgezeigt. So sei unter anderem die Kommunikation mit Anwendern der betroffenen Repositories nicht ideal gewesen. Zudem war der Mechanismus zum Widerruf der Zugangsdaten schlecht implementiert. Es gab darüber hinaus kein Backup der Details der Gentoo-Organisation auf GitHub. Systemd, eines der drei betroffenen Repositories, war kein Spiegel eines Gentoo-Repository, sondern direkt auf Github gespeichert.

    Auswirkungen

    Die Gentoo-Organisation auf GitHub war als Folge des Einbruchs für fünf Tage gesperrt. Eine unangenehme Folge des Einbruchs war zudem, dass alle früheren Pull Requests  von den zugehörigen Commits getrennt und geschlossen wurden. Das konnte von GitHub nicht rückgängig gemacht werden, sodass Anwender ihre Pull Requests erneut öffnen müssen.

    Laute Einbrecher

    Die Attacke verlief relativ laut, was zur schnellen Entdeckung beitrug. Einerseits wurden durch das Entfernen aller Konten die Entwickler per E-Mail informiert. Zum anderen erzwangen der oder die Täter ihre Änderungen mit dem Kommando git push –force. Damit hatten die Einbrecher selbst verhindert, dass ihre Änderungen lautlos von Anwendern mit einem git pull auf ihre Rechner gezogen werden konnten.

    Lehren gezogen

    Der Originalcode von Gentoo war zu keinem Zeitpunkt gefährdet, da er sich auf Servern der Organisation befindet, auf GitHub liegt lediglich eine Kopie. Die Entwickler selbst arbeiten fast ausschließlich mit dem Originalcode, während Beiträge aus der Community auch über die Gentoo-GitHub-Organisation vorgenommen werden. Als eine der Lehren aus dem Vorfall forciert Gentoo jetzt die Verwendung von Zwei-Faktor-Authentifizierung (2FA) für Konten auf GitHub. Viele Anwender nutzten diese doppelte Absicherung bereits vor dem Vorfall, aber nicht alle.