Privilege Elevation

[andy_m4]

Es soll hier darum gehen, so verschiedene Möglichkeiten der Privilege Elevation zu diskutieren.

Hin und wieder benötigt man ja mehr System-Rechte, als man gewöhnlich als Useraccount hat. Wenns z.B. darum geht, Software zu installieren usw.
Und da gibts ja mehrere Möglichkeiten.

Das einfachste ist sicher das SUID-Bit. Allerdings ist das nicht sehr granular. Es wirkt nur auf ein Programm als Gesamtes und dann auch für alle User-Accounts auf dem System.
Etwas mehr kann man mit dem Programm su machen. Was einem aber auch zu viel Rechte einräumt. Außerdem nötigt einem das noch das Passwort des Zielaccounts (z.B.: root) einzugeben, was man ja auch nicht immer möchte.

Eine feinere Konfiguration ermöglicht das allseits bekannte sudo. Da lässt sich ja genau festlegen, welcher Benutzer (oder Benutzergruppe) welchen Befehl unter welchem effektiven User mit welchen Parametern ausgeführt werden kann.
In eine ähnliche Richtung gehen ja auch sudo-rs (quasi eine sudo-Implementierung in Rust) und doas, welches schlanker ist und ich von der Konfigurationssyntax (doas.conf(5)) her angenehmer finde.
systemd bietet ja mit run0 etwas, was so ähnlich ist.

Das Problem: Es wirkt auf Programme und nicht auf Rechte als solches.
In die Richtung geht dann eher so was wie Capapbilities oder auch PolKit, welches dann aber schon wieder recht komplex ist.
Und dann gibts natürlich noch die richtig fetten Lösungen wie SELinux, die aber oft Overkill sein dürften.

Wie macht ihr das, wenn ihr Privilege Elevation benötigt? Und gibts vielleicht noch andere praktikable Ansätze?

 

[Linuxfreakgraz]

sudo ganz normaler Standard oder doas als ich FreeBSD ausprobiert habe.

 

[CasualP]

Was hast du denn genau vor? Ich nutze Linux schon seit über 20 Jahren und mir hat sudo (und in den Anfangszeiten su) immer gereicht. Aber dein Usecase mag vielleicht anders sein als meiner.

 

[CoMo]

systemd bietet ja mit run0 etwas, was so ähnlich ist

Heard it here first 😅 danke, das werde ich mir mal genauer anschauen. Der Prompt gefällt mir.

root@pve:~# run0
🦸 root@pve:~#

Wie macht ihr das, wenn ihr Privilege Elevation benötigt? Und gibts vielleicht noch andere praktikable Ansätze?

Ich melde mich auf allen meinen Server-Systemen via SSH als root an. Mit SSH-Key natürlich.

Auf meinen Desktop-Systemen, meist Ubuntu, nutze ich einfach sudo, wie vermutlich 99% der User.

 

[foofoobar]

Das einfachste ist sicher das SUID-Bit. Allerdings ist das nicht sehr granular. Es wirkt nur auf ein Programm als Gesamtes

Man kann auch root wieder wegwerfen, oder non-root-Prozesse abforken.

und dann auch für alle User-Accounts auf dem System.

Oder man stellt das suid-binary einfach in ein Directory wo nur eine Gruppe oder User Zugriff drauf hat.
Und natürlich kann das suid-binary beliebigen Kram tun.

 

[AlphaKaninchen]

Heard it here first 😅 danke, das werde ich mir mal genauer anschauen. Der Prompt gefällt mir.

Ist aber noch nicht ganz ausgereift, dnf in fedora geht z.B. nur in einer per run0 geöffneten Shell nicht aber direkt mit run0 dnf ...

Ergänzung (4. März 2026)

Wie macht ihr das, wenn ihr Privilege Elevation benötigt? Und gibts vielleicht noch andere praktikable Ansätze?

Bei Dingen die Wiederholt laufen systemd service anlegen, da kann man sich mit Sandboxing, Capabilities, User, Gruppe usw austoben.

 

[Astorek86]

Je nachdem, wie tief man graben möchte: Alle Binaries, Pfade (etc.) in dieselben Gruppen unterteilen in der sich auch der Nutzer befindet, und die Rechte entsprechend setzen.

Je nach Dateisystem kann man mittels ACL auch deutlich mehr Rechte ausschöpfen als die Linux-typischen "User-Gruppe-Andere, Lesen-Schreiben-Ausführen"-Geschichte. Dann kann man mittels ACL die zusätzlichen Rechte setzen und bei Bedarf auch wieder löschen.

Bisher hab ich das aber ehrlichgesagt nur auf meiner Arbeitsstelle gebraucht, wenn z.B. zwei Gruppen auf eine Docker-Schnittstelle Zugriff haben dürfen...

Im privaten Umfeld nutze ich halt nur sudo^^...

 

[Iapetos]

Benutze nur noch run0 unter arch linux, mir fehlt bisher nichts. Konnte meinen AUR helper (aura) nach dem letzten Update auch darauf konfigurieren.

Generell bin ich ziemlich begeistert von all den Dingen, die derzeit aus der systemd-Entwicklerecke kommt. Manchmal hakt es vielleicht an einigen Stellen, die Richtung finde ich aber grundsätzlich gut. Als nächstes darf dann bald dbus sterben.

 

[Donnerkind]

Heard it here first 😅 danke, das werde ich mir mal genauer anschauen. Der Prompt gefällt mir.

Dito. Mir gefällt auch der leicht rötliche Hintergrund in Konsole (auch wenn er mich ziemlich an die Standard-Hintergrundfarbe in Ubuntu erinnert 🫣).

Ist aber noch nicht ganz ausgereift, dnf in fedora geht z.B. nur in einer per run0 geöffneten Shell nicht aber direkt mit run0 dnf ...

Benutze nur noch run0 unter arch linux

Ich probiers auch gerade mit meinem Miniskript für pacman -Syu aus und es löppt einfach.™ Again what learned.

 

[andy_m4]

doas als ich FreeBSD ausprobiert habe.

Wobei man bei FreeBSD ja alternativ auch mdo hat, welches ja jetzt mit FreeBSD 15 auch ganz gut benutzbar wird. Das ist jetzt zwar kein doas-Replacement. Aber für viele Szenarien funktioniert es gut und es ist Bestandteil des Systems und man muss nix extra (sudo, doas etc.) installieren.

Das FreeBSD-Journal hat auch einen ganz guten Artikel zu mdo.

Was hast du denn genau vor?

Es geht hauptsächlich darum unterschiedliche Möglichkeiten einfach mal zu beleuchten.

Man kann auch root wieder wegwerfen, oder non-root-Prozesse abforken.

Ja. Kann man. Das hängt dann allerdings an der Programmierung des Programms.
Ich würde hier im Thread eher mein Fokus auf Dinge legen, die ohne Änderung am jeweiligen Programm funktionieren.

Oder man stellt das suid-binary einfach in ein Directory wo nur eine Gruppe oder User Zugriff drauf hat.

Ja. Man kann es mit anderen Zugriffsrechtsbeschränkungen kombinieren.

Und natürlich kann das suid-binary beliebigen Kram tun.

Ja eben. Und das will man vielleicht nicht immer unbedingt.
Ich meine, auch hier kann man ja Dinge kombinieren. Weil SUID heißt ja nicht, das das Programm root-Rechte hat, sondern mit den Rechten die der Eigentümer der Programmdatei hat. Man kann also einen eigenen Useraccount benutzen der die nötigen Rechte kriegt und Eigentümer der Programmdatei wird (bzw. analog auch mit Benutzergruppen und SGID).

Bei Dingen die Wiederholt laufen systemd service anlegen, da kann man sich mit Sandboxing, Capabilities, User, Gruppe usw austoben.

Ja. Kann man in solchen Fällen natürlich auch machen.

Als nächstes darf dann bald dbus sterben

Zugunsten von kdbus? Vielleicht unternimmt ja mal wieder jemand einen Anlauf.

Ergänzung (5. März 2026)

meist Ubuntu, nutze ich einfach sudo, wie vermutlich 99% der User.

Ja. Und unglücklicherweise ja gar nicht in Form von feingranularer Rechtevergabe, sondern eher so im Blankovollmacht-Style a-la
%sudo ALL=(ALL:ALL) ALL
Hinzu kommt, das sudo relativ fett(*) ist und damit den security best practise für SUID-Binarys zuwiderläuft, was dann wenig überraschend ein entsprechend langen Security-Record nachsich zieht.
Was natürlich insbesondere dann unglücklich ist, wenn man nicht mal annähernd die Features von sudo ausschöpft.
Wobei ubuntu ja immerhin inzwischen auf sudo-rs setzt.

*)
Nur mal so die Sourcecode-Größe im Vergleich, um mal ein Anhaltspunkt zu kriegen:
sudo > 10 MB
sudo-rs > 4 MB
doas ca. 120 KB

 

[foofoobar]

Ich meine, auch hier kann man ja Dinge kombinieren. Weil SUID heißt ja nicht, das das Programm root-Rechte hat, sondern mit den Rechten die der Eigentümer der Programmdatei hat. Man kann also einen eigenen Useraccount benutzen der die nötigen Rechte kriegt und Eigentümer der Programmdatei wird (bzw. analog auch mit Benutzergruppen und SGID).

Das ist gängige Praxis.

Aber wenn ich dich richtig verstehe willst du beliebige Programme einschränken?

 

[andy_m4]

willst du beliebige Programme einschränken?

Wie bereits gesagt geht es darum mal so unterschiedliche Möglichkeiten zu diskutieren, wie man sich (temporär) Rechte verschaffen und (von mir aus auch) sie beschneiden kann.

 

[netzgestaltung]

ich leg mir am server einen user an, der nicht root ist und gebe den in die sudoers gruppe. der kann sich mit ssh-key anmelden, root/root-login gibts bei mir nicht.

Wenn der User irgendwo arbeiten muß wo ein anderer besitzer ist, zb nginx, wird er der gruppe hinzugefügt und die Dateiberechtigungen für die Gruppe angepasst. Am besten ist das ein Test System wärend das auf einer Prod Ebene dann nicht mehr gemacht wird.

 

[foofoobar]

Wie bereits gesagt geht es darum mal so unterschiedliche Möglichkeiten zu diskutieren, wie man sich (temporär) Rechte verschaffen und (von mir aus auch) sie beschneiden kann.

In einem Umfeld wo das Zeug laufen muss oder geht es um privates frickeln?

 

[Iapetos]

Zugunsten von kdbus? Vielleicht unternimmt ja mal wieder jemand einen Anlauf.

Eher unwahrscheinlich. Der Trend zeigt auf varlink, und das ist wohl auch gut so.

 

[andy_m4]

In einem Umfeld wo das Zeug laufen muss oder geht es um privates frickeln?

Von mir aus beides.

Wobei "muss laufen" ja auch in mehrere Richtungen geht. Im typischen Firmenumfeld wird man vor allem die Wege beschreiten, das das gewählte System präferiert. Da will man eher keine Sonderlocken drehen.
Dann gibts ja noch die Möglichkeit, das man eine Appliance bauen will. Da kann man natürlich eher mal eigene Lösungen/Vorgehensweisen realisieren.

Der Trend zeigt auf varlink, und das ist wohl auch gut so.

varlink. Gut zu wissen.