Erste stabile Version der speichersicheren sudo-Implementierung sudo-rs veröffentlicht

 (memorysafety.org)
1 Punkte von GN⁺ 2023-11-07 | 1 Kommentare | Auf WhatsApp teilen
  • sudo-rs, eine Neuimplementierung von sudo in Rust für den Wechsel über Berechtigungsgrenzen hinweg, wurde als erste stabile Version veröffentlicht
  • Eine zentrale Motivation für die Neuimplementierung in Rust ist die Schätzung, dass etwa ein Drittel der Sicherheitsbugs im ursprünglichen sudo auf Probleme beim Speichermanagement zurückging
  • sudo-rs reduziert die Angriffsfläche, indem weniger genutzte Funktionen ausgelassen werden; die Testsuite wurde auch genutzt, um Bugs im ursprünglichen sudo zu finden
  • Wolfi Linux OS enthält sudo-rs bereits, und Chainguard ist der Ansicht, dass Verbesserungen an sicherheitskritischen Kernwerkzeugen Auswirkungen auf die gesamte Branche haben können
  • Ein externes Sicherheitsaudit soll im September 2023 beginnen; danach geht die Arbeit in Milestone 4 mit Schwerpunkt auf Enterprise-Funktionen über

sudo-rs: sudo neu in Rust implementiert

  • Prossimo hat das erste stabile Release von sudo-rs veröffentlicht
  • sudo-rs ist ein Projekt, das das unter Linux häufig verwendete sudo-Utility, mit dem die Berechtigungsgrenze zwischen Benutzerkonten und Administratorkonten überschritten wird, in Rust neu implementiert
  • Das sudo-rs-Projekt konzentriert sich darauf, die Sicherheit gegenüber dem ursprünglichen sudo zu erhöhen
    • Durch die Verwendung von Rust wird Speichersicherheit erreicht
    • Ausgangspunkt ist die Schätzung, dass etwa ein Drittel der Sicherheitsbugs im ursprünglichen sudo Probleme beim Speichermanagement waren
    • Durch das Auslassen weniger häufig genutzter Funktionen wird die Angriffsfläche reduziert
    • Es wurde eine umfangreiche Testsuite entwickelt, die auch Bugs im ursprünglichen sudo gefunden hat

Stand der Einführung und nächste Schritte

  • Wolfi Linux OS enthält sudo-rs bereits
  • Dan Lorenc, CEO und Mitgründer von Chainguard, sagt, dass Speichersicherheit beim Aufbau von Wolfi oberste Priorität hatte, und sieht Verbesserungen an sicherheitskritischen Kernwerkzeugen wie sudo als potenziell sehr einflussreich für die gesamte Branche
  • sudo-rs wurde von einem gemeinsamen Team von Tweede Golf und Ferrous Systems im Auftrag von Prossimo entwickelt
  • Das Projekt wurde im Dezember 2022 gestartet, und ein externes Sicherheitsaudit des sudo-rs-Codes soll im September 2023 beginnen
  • Nach dem Audit wechselt das Team zu Milestone 4 des Arbeitsplans, der sich auf Enterprise-Funktionen konzentriert
  • Das ursprüngliche C-basierte sudo-Utility wird seit Langem von Todd C. Miller gepflegt, der auch die Implementierung von sudo-rs beratend unterstützt hat
  • Die NLnet Foundation hat das Audit von sudo-rs finanziert, und Amazon Web Services unterstützt diese Arbeit sowie die Umstellung auf speichersichere Software

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-11-07
Hacker-News-Kommentare

  • Als einer der ursprünglichen Entwickler von sudo (https://en.wikipedia.org/wiki/Sudo) habe ich in den letzten 43 Jahren miterlebt, wie es fast vollständig neu geschrieben und fortlaufend von Bugs befreit wurde.
    Man kann wohl sagen, dass es unter den UNIX-Befehlen einer der am stärksten auf Sicherheitslücken geprüften ist, und die gefundenen Schwachstellen wurden behoben.
    Ich frage mich, ob ein einzelnes Entwicklerteam ein Tool, das Tausende Entwickler und Sicherheitsexperten untersucht haben, vollständig neu implementieren kann, ohne dabei auch nur ein oder zwei neue Bugs einzubauen.
    Ich frage mich, ob die Sprache Rust irgendetwas hat, das die Möglichkeit, Bugs einzuführen, auf magische Weise vollständig beseitigt.

    • Für die Arbeit an sudo kann man nur dankbar sein, und ich halte es für ein wirklich unschätzbares Tool im Alltag vieler Menschen.
      Aus Sicht der sudo-rs-Entwicklung wollten wir die bestehende Arbeit nie entwerten, und uns ist sehr bewusst, dass insbesondere am Anfang auch unsere Implementierung nicht frei von Bugs sein wird.
      Persönlich konnte ich durch die Rust-Version Bereiche angehen, die ich normalerweise nur schwer berühren würde, weil ich wenig Vertrauen darin habe, relativ sicheren C-Code zu schreiben.
      Zumindest haben wir durch diese Arbeit bereits einige Bugs im bestehenden sudo gefunden, und selbst wenn 43 Jahre lang daran korrigiert wurde, ist es schwer, dass solche Software völlig bugfrei bleibt, solange sich die Umgebung ringsherum ändert.
      Solange man zusammenarbeitet und aus der Arbeit und den Fehlern der anderen lernt, ist ein bisschen Alternative nichts Schlechtes.
    • Was auch immer in den letzten 43 Jahren passiert ist: 2021 gab es mit Baron Samedit eine breit ausnutzbare Speicherbeschädigungs-Schwachstelle.
    • Ein fortgeschrittenes Typsystem, Borrow Checking und speichersichere Sprachen helfen definitiv sehr, beseitigen aber natürlich nicht alle Bugs.
      Das Beste, was Entwickler bei RiiR tun können, ist, Best Practices zu folgen und aus früheren Fehlern zu lernen.
      In 43 Jahren hat es große Fortschritte gegeben, und allein der Verzicht auf C-String-Verarbeitung entfernt schon zahllose Bugs, noch bevor man über Speichersicherheit spricht.
      Wer heute einen sicheren sudo-Ersatz bauen will, kann selbst nur mit C deutlich besser abschneiden als früher, und das OpenBSD-Projekt zeigt das ziemlich gut.
      Wenn man viele der scharfen Kanten, die OpenBSD-Code vermeidet, bereits auf Sprachebene beseitigt, hat man einen besseren Start; trotzdem braucht es weiterhin viel Sorgfalt und Erfahrung, und eine Programmiersprache kann das nicht ersetzen.
      Es ist zumindest eine ernsthafte Prüfung wert, sollte aber meiner Meinung nach vorerst nicht als Standard ausgeliefert werden.
    • Ich will Erfahrung nicht kleinreden, und ich erwarte durchaus, dass dieses Projekt manche Schmerzen erneut entdecken wird. Wichtig ist aber auch, dass wir nicht die Lebenswerke von Newton, Leibniz und Maxwell exakt wiederholen müssen, um klassische Physik richtig zu verstehen.
      Heute steht das im Lehrplan der Oberstufe; wer ihn besteht, kann damit ziemlich gut umgehen, und mit etwas mehr Aufwand kann man sehr gut beherrschen, wofür sie ihr Leben lang gebraucht haben.
      Das liegt daran, dass wir auf den Schultern von Riesen stehen können, Rückblick sowie bessere Technik- und Lernmethoden haben und nicht all ihre Fehler wiederholen müssen.
      Wenn der ursprüngliche Entwickler sudo heute mit seiner jetzigen Erfahrung und seinem Wissen von Grund auf neu schreiben würde, könnte er es mit hoher Wahrscheinlichkeit in viel weniger Zeit sauberer und einfacher bauen.
      Das wertet die bisherige Arbeit und Erfahrung nicht ab, sondern bedeutet, dass es nicht unmöglich ist, diese Erfahrung in kürzerer Zeit in etwas Besseres zu verwandeln.
    • Bei Speichersicherheit stimmt das; die Sprache macht es viel einfacher, standardmäßig sicher zu sein, aber gegen Logikfehler tut sie nichts.
      Allerdings machen beim Ersetzen von sudo oder anderen Tools in C Schwachstellen wie Nullpointer oder Puffer-Missbrauch leicht 50 % des Gesamtbilds aus.

  • Die zwei Punkte, die dieses Projekt hervorhebt, werden meiner Meinung nach sogar häufiger übersehen als der Einsatz von Rust.
    Weniger genutzte Funktionen wegzulassen, um die Angriffsfläche zu reduzieren, und eine umfangreiche Testsuite zu entwickeln, die sogar Bugs im bestehenden sudo gefunden hat.
    Beim Schreiben sicherheitskritischen Codes sind solche Dinge wichtiger, als ihn in Rust neu zu schreiben.

  • Wenn man annimmt, dass das Ziel dieses Projekts ein Ersatz für sudo ist, finde ich es etwas beunruhigend, „weniger genutzte Funktionen ausgelassen“ einfach so abzutun.
    Wichtig ist, welche Funktionen das sind, wie wenig sie genutzt werden und auf welche Weise es bei Konfigurationen, die solche Funktionen verwenden, fehlschlägt.
    Edit: Im GitHub-README scheinen einige Einschränkungen zusammengefasst zu sein: https://github.com/memorysafety/sudo-rs#differences-from-ori...

    • Eine der fehlenden Funktionen ist sudoedit bzw. sudo -e.
      Ich nutze das häufig, wenn ich Dateien unter /etc oder Dateien bearbeiten muss, für die mein Benutzer keine Rechte hat. Dieses Flag kopiert die Datei zuerst an einen temporären Ort, den mein Benutzer bearbeiten darf, und startet dann den Texteditor mit meinen Benutzerrechten, ohne sudo-Rechte.
      Der Editor wird über die Umgebungsvariable $SUDO_EDITOR festgelegt, und nach dem Schließen wird die Datei nur dann mit den ursprünglichen Rechten zurückkopiert, wenn es Änderungen gab.
      Das Gute daran ist, dass der Editor nicht als root, sondern als mein Benutzer läuft und dadurch meine Benutzereinstellungen und Plugins lädt.
    • Eine Funktion, die nicht als fehlend aufgeführt ist, ist die Möglichkeit, make me a sandwich auszuführen (https://github.com/sudo-project/sudo/blob/main/Makefile.in#L...)
    • Eine Funktion, die in größeren Umgebungen genutzt wird, aber weder auf der sudo-rs-Roadmap steht noch implementiert ist, ist LDAP-Unterstützung.
      Beim normalen sudo kann man über eine zentrale LDAP-Konfiguration die sudo-Rechte für das gesamte Netzwerk verwalten und zentral Regeln erstellen, die nach Zeit, Host, Benutzer und Befehl eingeschränkt sind.
      Ohne dass ein einfacher Syntaxfehler potenziell die gesamte Konfiguration außer Kraft setzt; in diesem Fall wird nur die betreffende Regel ignoriert.
    • Da Systemadministratoren auch den Übergang zu systemd überstanden haben, dürften sie so etwas wohl verwalten können.
      Es wird sicher auch gute technische Dokumentation geben, und da dies ein werblicher Release-Text ist, ist er meines Erachtens nicht der Ort, an dem man eine Liste fehlender Funktionen sucht.
    • Dass eines der grundlegendsten UNIX-Werkzeuge überhaupt so viele Funktionen enthält, ist an sich ein viel größeres Warnsignal.

  • Betrachtet man den Unterschied zwischen Apache-2.0+MIT und GPL-2.0, kann man zwar speichersichere su/sudo-rs bekommen, aber wer sie in Binärform verteilt, ist nicht verpflichtet, den beim Build verwendeten Quellcode samt möglicher Änderungen offenzulegen.

    • Genau diesen Kommentar wollte ich auch schreiben.
      Ich bin sehr besorgt, dass der Trend, GPL-Werkzeuge durch Rust-Neuschreibungen unter MIT/Apache-Lizenz zu verdrängen, irgendwann zu proprietärem Linux führt, aber das ursprüngliche sudo steht nicht unter der GPL.
      Es ist eine Lizenz im ISC/MIT-Stil [1].
      1. https://www.sudo.ws/about/license/
    • Bei solchen Kernkomponenten von der GPL wegzugehen, ist eine sehr schlechte Idee.
      Aus genau dem oben genannten Grund; ich schreibe das, um dieses Problem hervorzuheben.
    • Sudo steht nicht unter der GPL, sondern unter einer sehr permissiven Lizenz aus der ISC-Familie[0].
      su scheint tatsächlich GPL zu sein.
      [0]: https://www.sudo.ws/about/license/
    • Ist das wirklich schlecht?
      Man hat die Freiheit, eine solche Distribution nicht zu verwenden.
      Aus Sicherheitssicht könnte ein böswilliger Akteur anderen Quellcode zeigen als den, den er als Binärdatei verteilt.
      Das gilt unabhängig davon, ob GPL oder nicht.
    • Ob gut oder schlecht: Die Nutzung der GPL nimmt ab, und auch die Zukunft des Linux-Kernels ist nicht garantiert.
      Im Bereich freier und Open-Source-UNIX-artiger Betriebssysteme für IoT verwenden alle Kandidaten, einschließlich des von der Linux Foundation geförderten ZephyrOS, eine Mischung aus Apache-, MIT- und BSD-Lizenzen.
      Wenn die GPL-Generation verschwindet, wird in nicht allzu ferner Zukunft ein UNIX-artiges Betriebssystem mit für Großunternehmen attraktiverer Lizenz als weitere Alternative zu den Betreuern des Linux-Kernels auftauchen.

  • Es wäre interessant, eine Debian-Abspaltung zu sehen, die das hier mit den in Rust implementierten GNU Coreutils kombiniert.
    Das könnte große Vorteile bei Speichersicherheit und Performance bringen.
    [1] https://github.com/uutils/coreutils

    • Ich frage mich, wie weit wir noch von einem Rust-basierten UNIX-User-Space entfernt sind.
      Zumindest müsste man wohl keinen C-Compiler implementieren.

  • Wird hier Scheiße poliert?
    Eine bessere Neuimplementierung ist natürlich gut, aber warst du nicht überrascht, als du von den seltsamen sudo-Funktionen gelesen hast?
    Selbst scheinbar gewöhnliche Teile sind sehr seltsam und subtil und dadurch entsprechend anfällig.
    Wer sudo „intensiv“ nutzt, sollte überlegen, ob es andere Wege gibt.

  • Es wäre gut, ein Validierungs-/Prüf-Flag oder Tool zu haben, das die aktuelle sudo-Konfiguration testweise ausführt und ausgibt, welche Teile sudo-rs nicht unterstützt.
    Projekte wie dieses brauchen Portierungshilfen, damit der Umstieg reibungslos verläuft.

  • Wenn ich mich richtig erinnere, waren die jüngsten sudo-Schwachstellen alle Logikfehler und keine Probleme mit Speichersicherheit.
    Eine Neuschreibung ist gut, aber man sollte nicht so tun, als könnten keine neuen Bugs entstehen, weil jemand missverstanden hat, wie etwas funktioniert, oder einfach einen ganz normalen Fehler gemacht hat.

    • 2021: https://nvd.nist.gov/vuln/detail/CVE-2021-3156
      2019: https://nvd.nist.gov/vuln/detail/CVE-2019-18634
    • Wer tut denn so?
      Ich sehe viele Aussagen zur Speichersicherheit, aber es wirkt nicht so, als würde dieses Projekt behaupten, andere Arten von Bugs würden sicher eliminiert.
    • Auf dieselbe Weise können auch im bestehenden sudo neue Speicherfehler entstehen.
      Die Angriffsfläche durch statische Prüfungen zu reduzieren, wirkt langfristig wie der bessere Deal.

  • doas ist ein deutlich einfacheres Werkzeug, das dasselbe tut.
    Ich verstehe nicht ganz, warum es nicht stärker genutzt wird.

  • doas ist 43184 Byte groß und macht alles, was ich brauche.
    Dieser sudo-Exploit war ein Weckruf.
    Wenn du noch nicht umgestiegen bist, lohnt sich ein Blick auf opendoas (Debian-Paket).