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 (Heute um 20:20)

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.