{"id":1151985,"date":"2026-07-08T14:20:13","date_gmt":"2026-07-08T14:20:13","guid":{"rendered":"https:\/\/www.europesays.com\/de\/1151985\/"},"modified":"2026-07-08T14:20:13","modified_gmt":"2026-07-08T14:20:13","slug":"rootasrole-4-0-mehr-kontrolle-als-bei-sudo","status":"publish","type":"post","link":"https:\/\/www.europesays.com\/de\/1151985\/","title":{"rendered":"RootAsRole 4.0: Mehr Kontrolle als bei sudo"},"content":{"rendered":"
    \n
  1. \n

    RootAsRole 4.0: Mehr Kontrolle als bei sudo<\/p>\n<\/li>\n<\/ol>\n

    Mit RootAsRole 4.0 haben die Entwickler ihres Linux-\/Unix-Werkzeugs zur Rechtevergabe eine neue Hauptversion ver\u00f6ffentlicht. RootAsRole versteht sich als Alternative zu sudo und delegiert Administratorrechte rollenbasiert, sodass Nutzer nur die f\u00fcr eine Aufgabe ben\u00f6tigten Berechtigungen erhalten. Version 4.0 bringt unter anderem ein neues Ausf\u00fchrungsmodell f\u00fcr privilegierte Programme, Richtlinien aus Verzeichnissen sowie Einschr\u00e4nkungen auf bestimmte Arbeitsverzeichnisse.<\/p>\n

    Weiterlesen nach der Anzeige<\/p>\n

    Obwohl der Versionssprung auf 4.0 eine neue Hauptversion markiert, soll das Update laut Projekt keine inkompatiblen \u00c4nderungen enthalten. Stattdessen begr\u00fcnden die Entwickler den Schritt in den Release Notes<\/a> vor allem mit einer grundlegenden \u00dcberarbeitung der Programmausf\u00fchrung.<\/p>\n

    Neues Ausf\u00fchrungsmodell f\u00fcr privilegierte Programme<\/p>\n

    Die wichtigste technische Neuerung betrifft die Ausf\u00fchrung privilegierter Prozesse. RootAsRole orientiert sich dabei k\u00fcnftig am Modell von sudo statt an doas. W\u00e4hrend doas das Zielprogramm direkt startet, schaltet sudo einen zus\u00e4tzlichen Prozess dazwischen. Er \u00fcberwacht die Programmausf\u00fchrung und kann Ein- und Ausgaben sowie administrative Interaktionen kontrollieren. Nach Ansicht der Entwickler erh\u00f6ht dieses Modell trotz des gr\u00f6\u00dferen Codeumfangs die Sicherheit gegen\u00fcber einer direkten Ausf\u00fchrung.<\/p>\n

    Neu ist au\u00dferdem eine Option, Befehle nur aus einem bestimmten Arbeitsverzeichnis heraus zu erlauben. Administratoren k\u00f6nnen beispielsweise festlegen, dass ein Build- oder Deployment-Werkzeug ausschlie\u00dflich innerhalb eines definierten Projektverzeichnisses gestartet werden darf. Das soll Fehlbedienungen erschweren und den m\u00f6glichen Einsatzbereich privilegierter Befehle weiter einschr\u00e4nken. Die Entwickler weisen allerdings darauf hin, dass die Wirksamkeit dieser Funktion von einer korrekt abgesicherten Dateisystemkonfiguration abh\u00e4ngt.<\/p>\n

    Ebenfalls neu ist eine verzeichnisbasierte Richtlinienverwaltung. Anstatt s\u00e4mtliche Regeln in einer Konfigurationsdatei zu sammeln, kann RootAsRole nun mehrere Policy-Dateien aus einem Verzeichnis einlesen. Das erleichtert etwa eine getrennte Richtlinienverwaltung pro Benutzer oder sorgt bei umfangreichen Installationen f\u00fcr eine \u00fcbersichtlichere Organisation.<\/p>\n

    Au\u00dferdem haben die Entwickler die Build-Konfiguration erweitert, das Projekt auf die Rust Edition 2024 umgestellt und die interne Projektstruktur modernisiert. Auch Werkzeuge und Linting-Regeln wurden laut Release Notes \u00fcberarbeitet.<\/p>\n

    Rollen statt Root-Rechte<\/p>\n

    Weiterlesen nach der Anzeige<\/p>\n

    RootAsRole verfolgt das Prinzip der geringsten Rechte (Principle of Least Privilege). Anders als klassische sudo-Konfigurationen, die Benutzern h\u00e4ufig weitreichende Root-Rechte \u00fcbertragen, vergibt das Werkzeug nur die Rechte, die f\u00fcr eine konkrete Aufgabe erforderlich sind. Grundlage daf\u00fcr ist ein rollenbasiertes Zugriffskontrollmodell (Role-Based Access Control, RBAC) mit Rollen und Aufgaben sowie der Unterst\u00fctzung von Linux Capabilities, also feingranularen Kernel-Berechtigungen.<\/p>\n

    Dadurch l\u00e4sst sich beispielsweise festlegen, dass ein Benutzer lediglich Netzwerkdiagnoseprogramme mit der Capability CAP_NET_RAW ausf\u00fchren darf, ohne vollst\u00e4ndige Root-Rechte zu erhalten. Erg\u00e4nzend unterst\u00fctzt RootAsRole Rollenhierarchien sowie statische und dynamische Trennung von Zust\u00e4ndigkeiten, um kritische Verwaltungsaufgaben auf mehrere Rollen aufzuteilen.<\/p>\n

    Hilfswerkzeuge f\u00fcr Administratoren<\/p>\n

    Zum Projekt geh\u00f6ren au\u00dferdem mehrere Werkzeuge f\u00fcr die Richtlinienverwaltung. Das Programm capable analysiert, welche Berechtigungen ein Befehl ben\u00f6tigt, w\u00e4hrend gensr aus Ansible-Playbooks passende Sicherheitsrichtlinien erzeugen kann. Laut Projekt soll das nicht nur die Erstellung feingranularer Regeln vereinfachen, sondern auch helfen, unerwartete \u00c4nderungen in Automatisierungsabl\u00e4ufen zu erkennen.<\/p>\n

    RootAsRole ist in Rust implementiert und unterst\u00fctzt Linux-Kernel ab Version 4.3. Das Projekt entstand am franz\u00f6sischen Informatikforschungsinstitut IRIT und wurde im Rahmen eines industriellen Promotionsprogramms gemeinsam mit Airbus Protect weiterentwickelt. Die Entwickler verweisen auf GitHub<\/a> auf mehrere wissenschaftliche Ver\u00f6ffentlichungen, die RootAsRole von den ersten Konzepten bis zur produktionsreifen Umsetzung begleiten.<\/p>\n

    Lesen Sie auchMehr anzeigenWeniger anzeigen<\/p>\n

    (fo<\/a>)<\/p>\n

    \n Dieser Link ist leider nicht mehr g\u00fcltig.\n <\/p>\n

    Links zu verschenkten Artikeln werden ung\u00fcltig,
    \n wenn diese \u00e4lter als 7\u00a0Tage sind oder zu oft aufgerufen wurden.\n <\/p>\n

    Sie ben\u00f6tigen ein heise+ Paket, um diesen Artikel zu lesen. Jetzt eine Woche unverbindlich testen \u2013 ohne Verpflichtung!<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"RootAsRole 4.0: Mehr Kontrolle als bei sudo Mit RootAsRole 4.0 haben die Entwickler ihres Linux-\/Unix-Werkzeugs zur Rechtevergabe eine…\n","protected":false},"author":2,"featured_media":1151986,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_share_on_mastodon":"0"},"categories":[135],"tags":[29,30,196,17699,24469,241840,4560,190,189,1687,73638,194,191,137413,193,192],"class_list":["post-1151985","post","type-post","status-publish","format-standard","has-post-thumbnail","category-wissenschaft-technik","tag-deutschland","tag-germany","tag-it","tag-linux","tag-open-source","tag-rootasrole","tag-rust","tag-science","tag-science-technology","tag-security","tag-sudo","tag-technik","tag-technology","tag-unix","tag-wissenschaft","tag-wissenschaft-technik"],"share_on_mastodon":{"url":"https:\/\/pubeurope.com\/@de\/116884801307038593","error":""},"_links":{"self":[{"href":"https:\/\/www.europesays.com\/de\/wp-json\/wp\/v2\/posts\/1151985","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.europesays.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.europesays.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/de\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/de\/wp-json\/wp\/v2\/comments?post=1151985"}],"version-history":[{"count":0,"href":"https:\/\/www.europesays.com\/de\/wp-json\/wp\/v2\/posts\/1151985\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/de\/wp-json\/wp\/v2\/media\/1151986"}],"wp:attachment":[{"href":"https:\/\/www.europesays.com\/de\/wp-json\/wp\/v2\/media?parent=1151985"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.europesays.com\/de\/wp-json\/wp\/v2\/categories?post=1151985"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.europesays.com\/de\/wp-json\/wp\/v2\/tags?post=1151985"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}