Connect with us

Entwicklung & Code

RootAsRole 4.0: Mehr Kontrolle als bei sudo


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Mit RootAsRole 4.0 haben die Entwickler ihres Linux-/Unix-Werkzeugs zur Rechtevergabe eine neue Hauptversion veröffentlicht. RootAsRole versteht sich als Alternative zu sudo und delegiert Administratorrechte rollenbasiert, sodass Nutzer nur die für eine Aufgabe benötigten Berechtigungen erhalten. Version 4.0 bringt unter anderem ein neues Ausführungsmodell für privilegierte Programme, Richtlinien aus Verzeichnissen sowie Einschränkungen auf bestimmte Arbeitsverzeichnisse.

Weiterlesen nach der Anzeige

Obwohl der Versionssprung auf 4.0 eine neue Hauptversion markiert, soll das Update laut Projekt keine inkompatiblen Änderungen enthalten. Stattdessen begründen die Entwickler den Schritt in den Release Notes vor allem mit einer grundlegenden Überarbeitung der Programmausführung.

Die wichtigste technische Neuerung betrifft die Ausführung privilegierter Prozesse. RootAsRole orientiert sich dabei künftig am Modell von sudo statt an doas. Während doas das Zielprogramm direkt startet, schaltet sudo einen zusätzlichen Prozess dazwischen. Er überwacht die Programmausführung und kann Ein- und Ausgaben sowie administrative Interaktionen kontrollieren. Nach Ansicht der Entwickler erhöht dieses Modell trotz des größeren Codeumfangs die Sicherheit gegenüber einer direkten Ausführung.

Neu ist außerdem eine Option, Befehle nur aus einem bestimmten Arbeitsverzeichnis heraus zu erlauben. Administratoren können beispielsweise festlegen, dass ein Build- oder Deployment-Werkzeug ausschließlich innerhalb eines definierten Projektverzeichnisses gestartet werden darf. Das soll Fehlbedienungen erschweren und den möglichen Einsatzbereich privilegierter Befehle weiter einschränken. Die Entwickler weisen allerdings darauf hin, dass die Wirksamkeit dieser Funktion von einer korrekt abgesicherten Dateisystemkonfiguration abhängt.

Ebenfalls neu ist eine verzeichnisbasierte Richtlinienverwaltung. Anstatt sämtliche 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ür eine übersichtlichere Organisation.

Außerdem 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 überarbeitet.

Weiterlesen nach der Anzeige

RootAsRole verfolgt das Prinzip der geringsten Rechte (Principle of Least Privilege). Anders als klassische sudo-Konfigurationen, die Benutzern häufig weitreichende Root-Rechte übertragen, vergibt das Werkzeug nur die Rechte, die für eine konkrete Aufgabe erforderlich sind. Grundlage dafür ist ein rollenbasiertes Zugriffskontrollmodell (Role-Based Access Control, RBAC) mit Rollen und Aufgaben sowie der Unterstützung von Linux Capabilities, also feingranularen Kernel-Berechtigungen.

Dadurch lässt sich beispielsweise festlegen, dass ein Benutzer lediglich Netzwerkdiagnoseprogramme mit der Capability CAP_NET_RAW ausführen darf, ohne vollständige Root-Rechte zu erhalten. Ergänzend unterstützt RootAsRole Rollenhierarchien sowie statische und dynamische Trennung von Zuständigkeiten, um kritische Verwaltungsaufgaben auf mehrere Rollen aufzuteilen.

Zum Projekt gehören außerdem mehrere Werkzeuge für die Richtlinienverwaltung. Das Programm capable analysiert, welche Berechtigungen ein Befehl benötigt, während gensr aus Ansible-Playbooks passende Sicherheitsrichtlinien erzeugen kann. Laut Projekt soll das nicht nur die Erstellung feingranularer Regeln vereinfachen, sondern auch helfen, unerwartete Änderungen in Automatisierungsabläufen zu erkennen.

RootAsRole ist in Rust implementiert und unterstützt Linux-Kernel ab Version 4.3. Das Projekt entstand am französischen Informatikforschungsinstitut IRIT und wurde im Rahmen eines industriellen Promotionsprogramms gemeinsam mit Airbus Protect weiterentwickelt. Die Entwickler verweisen auf GitHub auf mehrere wissenschaftliche Veröffentlichungen, die RootAsRole von den ersten Konzepten bis zur produktionsreifen Umsetzung begleiten.

Lesen Sie auch


(fo)



Source link

Entwicklung & Code

JetBrains bündelt KI-Tools für Unternehmen: Einheitliche Governance und Kosten


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Unter dem Sammelbegriff „JetBrains AI for Teams and Organizations“ hat JetBrains Dienste und Funktionen vorgestellt, die eine organisationsweite KI-Schicht für Teams und Unternehmen bilden und eine Skalierung der KI-Nutzung ermöglichen sollen. JetBrains will die Tools im Juli und August schrittweise auf seiner Plattform bereitstellen, vorerst nur für Geschäftskunden.

Weiterlesen nach der Anzeige

Hinter JetBrains AI for Teams and Organizations steckt die Idee, einer Fragmentierung der KI-Nutzung entgegenzuwirken. Entwicklerinnen und Entwickler können ihre bevorzugten KI-Werkzeuge wie Claude Code oder Gemini CLI wie gewohnt weiterverwenden. Gleichzeitig hält auf Unternehmensebene eine gemeinsame Infrastruktur für Governance, Kontext und Kostenmanagement Einzug – der Schritt von fragmentierter KI-Nutzung zu koordinierter Softwareentwicklung, wie JetBrains es selbst formuliert.

Langfristig will JetBrains mit seiner KI-Suite ein offenes System aufbauen, das Entwickler, KI-Agenten und Unternehmen an einen Tisch holt, ohne sie dabei in ein einziges Modell, eine bestimmte Bedienoberfläche oder einen festen Workflow zu zwängen. Die KI-Suite ist herstellerunabhängig ausgelegt. Externe Tools bindet sie über das Model Context Protocol (MCP) an, externe KI-Agenten über das Agent Client Protocol (ACP).

Vier der neuen Systemkomponenten sollen laut JetBrains in den nächsten Wochen bereitstehen. Eine Veröffentlichungsreihenfolge bleibt der Hersteller schuldig, nennt in seinem Blogbeitrag aber zuerst die „Team automations and cloud agents“. Diese Dienste führen KI-Agenten für langlaufende Aufgaben in verwalteten Cloud-Umgebungen autonom aus, wobei Repository-Ereignisse oder Zeitpläne als Auslöser fungieren. Automatisierungen bleiben für das gesamte Team sichtbar.

Ein weiterer Baustein ist die Funktion „JetBrains Context“. Sie stattet Agenten mit Repository-Wissen aus, damit sie komplexe Codebasen schneller verstehen. Die zentrale Verwaltung der KI-Tools übernehmen mit „JetBrains Central“ und dem Befehlszeilenwerkzeug „JetBrains Central CLI“ die Bausteine drei und vier.

Weiterlesen nach der Anzeige

Parallel zur Ankündigung stellt JetBrains seine KI-Lizenzen auf On-Demand-KI-Credits um, was wiederum nur für Geschäftskunden gilt. Unternehmen will man so in die Lage versetzen, KI-Investitionen zwischen Entwicklern aufzuteilen und über einen längeren Zeitraum zu verwalten, da die Credits länger gültig sind (12 Monate statt nur einen Monat). Die KI-Credits sollen auch zur Bezahlung künftiger Dienste genutzt werden können, zu denen JetBrains jedoch noch keine Angaben macht.

Lesen Sie auch


(mro)



Source link

Weiterlesen

Entwicklung & Code

GitHub-Alternative für KI-Entwickler: Entire startet eigenes Git-Netzwerk


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Weiterlesen nach der Anzeige

Entire, das neue Start-up von Ex-GitHub-CEO Thomas Dohmke, kündigt eine eigene Git-Infrastruktur an. Entwickler können in einer Vorschau der neuen Funktion ihre bestehenden GitHub-Repositories auf Entires Server spiegeln. Der Quellcode selbst bleibt auf GitHub, während Clone- und Pull-Anfragen über die regionalen Mirrors laufen.

Zukünftig sollen zudem öffentliche und private Git-Repositories direkt bei Entire gehostet werden können. Das soll nach Unternehmensangaben „in den kommenden Monaten“ folgen. Langfristig plant Entire ein vollständig dezentralisiertes Git-Netzwerk.

Das Ganze soll die Last von Zugriffen durch KI-Agenten verteilen. Dazu habe man Git entsprechend angepasst, um diese gleichzeitigen Agenten-Aktivitäten besser zu bewältigen. In eigenen Tests sei der Durchsatz dabei deutlich verbessert worden. Interessierte Nutzer können sich für eine Warteliste registrieren.

„Git war von Anfang an als verteiltes System gedacht“, sagt Entire-CEO Thomas Dohmke. Im „Zeitalter der KI-Agenten“ sei ein zentralisiertes Git-Hosting zur Einschränkung geworden: „Die Belastung durch Milliarden von Agenten und Entwicklern, die auf einen zentralen Server zugreifen, zeigt sich in Form von Rate-Limits, hoher Latenz oder sogar Ausfällen“.

Weiterlesen nach der Anzeige

Auch wenn es viele ebenfalls auf Git-basierende Alternativen wie Codeberg gibt, bleibt das zu Microsoft gehörende GitHub mit zuletzt mehr als 180 Millionen Nutzern und 630 Millionen dort gehosteten Softwareprojekten De-Facto-Standard für das Cloudhosting von Code.

Bis 2025 war der deutsche Entire-Gründer Thomas Dohmke selbst noch CEO bei GitHub. Im August 2025 kündigte er jedoch den Rückzug an, um nach eigenen Aussagen zu seinen Start-up-Wurzeln zurückzukehren. Entire gründete er Anfang 2026, dank Investoren ist das Start-up bereits jetzt mit 300 Millionen US-Dollar bewertet. Aktuell beschäftigt Entire 40 Personen, davon viele in Europa.


(dzi)



Source link

Weiterlesen

Entwicklung & Code

Freie Alternative zu Jira: OpenProject 17.6 integriert XWiki


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Mit Version 17.6 verbindet das Projektmanagement-Tool OpenProject die eigene Open-Source-Plattform mit der Wissensmanagement-Software XWiki. Zudem baut das Release die Scrum-Funktionen aus, verbessert Meetings und Administration und bringt mehrere sicherheitsrelevante Änderungen sowie zahlreiche Fehlerkorrekturen.

Weiterlesen nach der Anzeige

Wichtigste Neuerung ist die XWiki-Integration, die als Enterprise-Erweiterung für alle Kunden mit Corporate-Plan bereitsteht. Administratoren binden XWiki als externen Wiki-Provider ein, woraufhin Work Packages einen eigenen Wiki-Tab erhalten. Darüber zeigt OpenProject passende Wiki-Seiten an, legt neue an oder verknüpft bestehende Dokumente. Auch Querverweise zwischen beiden Systemen sind möglich: Entwickler greifen direkt aus einem Ticket auf Architektur- oder Betriebsdokumentation zu, und aus Wiki-Seiten führen Links zu den zugehörigen Aufgaben.

Laut dem Projekt richtet sich die Integration unter anderem an Organisationen, die proprietäre Kombinationen wie Jira und Confluence durch eine Open-Source-Lösung ersetzen wollen. Auch das integrierte Wiki von OpenProject erhält Verbesserungen: Es lässt sich künftig selbst als Wiki-Anbieter nutzen und über denselben neuen Reiter in Work Packages einbinden. Kleinere Installationen benötigen damit keine separate Wiki-Plattform mehr.

Im Bereich Scrum erweitert OpenProject die Backlog-Funktionen. Neu sind Sprint-Ziele, die sich beim Anlegen oder Bearbeiten eines Sprints festlegen lassen und anschließend für alle sichtbar im Sprint-Header erscheinen. Das soll Teams helfen, einzelne Aufgaben stärker an einem gemeinsamen Ziel auszurichten.

Hinzu kommt eine Übersicht sämtlicher Sprints eines Projekts. Sie zeigt Status, Laufzeiten und die Zahl der enthaltenen Work Packages. Außerdem lassen sich sogenannte Backlog Buckets nun direkt in Work Packages verwalten sowie in Tabellen filtern, gruppieren und sortieren. Diese Buckets dienen als Kategorien innerhalb des Product Backlogs, etwa um technische Schulden, Infrastrukturarbeiten oder Kundenanforderungen zu trennen, bevor sie in einen Sprint wandern. Das Teilen von Sprints (Sprint Sharing) ist zudem nun bereits im Basic Enterprise Plan enthalten – bisher war das Feature dem teureren Corporate-Plan vorbehalten.

Für Besprechungen führt OpenProject eine Funktion ein, mit der sich Tagesordnungspunkte direkt in Work Packages umwandeln lassen. Die Verknüpfung zwischen Meeting und Aufgabe bleibt erhalten.

Weiterlesen nach der Anzeige

Version 17.6 erweitert zudem die Administrationsfunktionen. Projektverantwortliche schalten Kostenarten künftig projektbezogen frei oder deaktivieren sie. Außerdem verwendet OpenProject projektbezogene semantische Kennungen nun durchgängig in CSV-, Excel- und PDF-Exporten für Meetings und Zeiterfassungen. Solche sprechenden Kennungen ersetzen numerische IDs etwa durch „ERP-2026“ oder „CRM-MIGRATION“. Nicht mehr benötigte Kennungen lassen sich künftig wieder freigeben.

Auch technisch bringt das Release einige Änderungen. CSV-Exporte maskieren jetzt Steuerzeichen, um Angriffe über Tabellenkalkulationen (CSV- oder Spreadsheet-Injection) zu erschweren. Die LDAP-Anbindung unterstützt zusätzliche Attribute für die Gruppensynchronisierung und schützt besser gegen Brute-Force-Angriffe. Zudem gelten die bereits eingeführten SSRF-Schutzmechanismen nun auch für Integrationen wie Nextcloud oder XWiki. Wer solche Dienste ausschließlich über private IP-Adressen betreibt, muss sie künftig auf eine Ausnahmeliste setzen.

Darüber hinaus überarbeitet das Projekt die Struktur seiner Meeting-API mit neuen Endpunkten und geänderten Ressourcenpfaden. Bestehende API-Integrationen müssen Anwender daher gegebenenfalls anpassen.

Neben den neuen Funktionen enthält OpenProject 17.6 zahlreiche Fehlerkorrekturen und Verbesserungen in Bereichen wie Dokumentenverwaltung, Barrierefreiheit, Mobilansicht und API.

OpenProject ist eine Open-Source-Plattform für Projektmanagement und Zusammenarbeit. Sie kombiniert klassische Projektplanung und agiles Arbeiten mit Ticketverwaltung („Work Packages“), Gantt-Diagrammen, Dokumentation, Meetings und Zeiterfassung. Die Software läuft auf eigener Infrastruktur und richtet sich vor allem an Unternehmen und Behörden, die Wert auf Datenhoheit legen.


(axk)



Source link

Weiterlesen

Beliebt