Microsoft startet Coreutils für Windows: eine einzelne binäre für Dutzende von POSIX-Befehlen und ihre Sicherheits-Dilemmas

Microsoft präsentiert in Build 2026 eine native Windows-Version von vielen traditionellen Linux-Befehlszeilenprogramme, verpackt als Coreutils für Windows und auf dem Open Source-Projekt gebaut uutils / choreutils, neu geschrieben in Rust. Neben der technischen Neuheit versucht diese Bewegung, die Reibung für Entwickler zu reduzieren, die zwischen Linux, macOS, WSL und Windows springen, indem sie die gleichen Befehle verwenden, ohne Skripte neu zu schreiben.

Das Paket, veröffentlicht und gepflegt von Microsoft in GitHub https: / / github.com / microsoft / choreutils, Gruppen choreutils, findutils und ein GNU-kompatibles Grep in einem einzigen Binär. Die Installation wird über WinGet erleichtert, was die Adoption in Windows-Umgebungen vereinfacht, erfordert aber auch Umdenken, wie PATH verwaltet und Shell Prioritäten.

Anstatt separate Ausführungsoptionen zu erstellen, verwendet Microsoft eine einzelne Choreutils. exe mit Dutzenden von NTFS Hardlinks (hardlinks) wie ls.exe, cp.exe, cat.exe, etc., die auf die gleiche Datei hinweisen. Durch das Aufrufen eines bestimmten Namens bestimmt die Binärdatei, welche Dienstprogramm auszuführen ist. Diese Technik erinnert sich an BusyBox und hat operative Vorteile, aber auch praktische und sicherheitspolitische Auswirkungen die bewertet werden sollte, bevor sie massiv eingesetzt wird.

Eine wichtige technische Implikation ist Kompatibilität: Windows ist nicht POSIX, so dass Dienste, die von POSIX-Mechanismen (wie chmod, chown, chroot, nohup oder Kill-Typ-Signale) sind nicht enthalten. Microsoft hat eine Kompatibilitätstabelle veröffentlicht, die Konflikte mit eingebauten PowerShell- und cmd-Befehlen beschreibt und erklärt, dass die Version ausgeführt wird, abhängig von der Reihenfolge der PATH- und PowerShell-Aliase. Das bedeutet, dass nicht alle Skripte "wie auch" ohne Beweise und Anpassungen funktionieren.

Aus Sicherheits- und Detektionsperspektive ändert sich der Fokus eines einzelnen Binärs mit mehreren Namen, wie Schutz- und Telemetriesysteme die Aktivität interpretieren: mehrere verschiedene Befehle zeigen die gleiche Datei und Hash-Signatur auf Festplatte, die verzerren oder bereichern EDR / AV Regeln, wenn nicht aktualisiert. Darüber hinaus erhöht das Hinzufügen einer Vielzahl von Diensten die Angriffsfläche - zum Beispiel Datei- und Netzwerkhandling-Tools könnten die seitliche Bewegung erleichtern, wenn sie mit hohen Berechtigungen ausgeführt werden - so müssen wir Berechtigungen und Nutzungen überprüfen.

Für Entwicklungsteams Ich empfehle, Coreutils in Nicht-Produktionsumgebungen und kontinuierlichen Integrationskorridoren zu testen, bevor es angenommen wird: Führen Sie Ihre Skripte, vergleichen Sie Zeilensprünge (LF vs CRLF), Berechtigungen und erwartete Fehler und passen Sie die automatischen Tests an. Wenn Ihre Pipeline von fehlenden POSIX-Dienstprogrammen abhängt, halten Sie WSL- oder Linux-Container für diese spezifischen Aufgaben.

Für Manager und Sicherheitsbeamte rate ich, die Authentizität des Pakets (Signaturen und Ursprung) zu überprüfen, die Installation durch Corporate Package Management Richtlinien zu kontrollieren und Erkennungsregeln anzupassen, um zu berücksichtigen, dass mehrere Befehle die gleiche ausführbare Karte können. Betrachten Sie, es zuerst in kontrollierten Gruppen einzusetzen und Telemetrie für Anomalien nach der Installation zu überwachen. Die offizielle Flügeluhrdokumentation ist eine nützliche Ressource für verwaltete Bereitstellungen: https: / / learn.microsoft.com / en-us / windows / Paketmanager / winget /.

Es wird auch empfohlen, die Liste der nicht enthaltenen Befehle zu überprüfen und Alternativen auszuwerten: Wo es keine Nutzungen aufgrund von Betriebssystembeschränkungen gibt, verwenden Sie WSL, Container oder native Tools, die POSIX-Verhalten emulieren. Die Beibehaltung der Klarheit darüber, welche Umgebung jede Aufgabe läuft, wird die Überraschungen in der Produktion reduzieren.

Kurz gesagt, Coreutils für Windows kann Multi-Plattform-Workflows beschleunigen und tägliche Reibung reduzieren, aber es ist keine transparente oder risikofreie Lösung. Prüfung, Bereitstellungsmanagement und Anpassung von Sicherheitsregeln sind notwendige Schritte, um ihre Vorteile zu nutzen, ohne dass bereits vorhandene Schwachstellen oder Risse in Rohrleitungen eingebracht werden.