Benutzer, Rollen und RBAC unter Solaris: warum root standardmässig eine Rolle ist und wie pfexec sudo ersetzt

Worum es geht

Oracle Solaris setzt privilegierte Administration über Role-Based Access Control (RBAC) um: Rechteprofile bündeln Privilegien und Autorisierungen und werden entweder direkt einem Benutzer zugewiesen oder einer Rolle, die ein Benutzer ausdrücklich übernehmen muss. Unter Solaris 11.4 ist root selbst standardmässig als Rolle eingerichtet und nicht als Benutzer, mit dem man sich direkt anmelden kann. Ein Administrator meldet sich also mit dem eigenen, namentlichen Benutzerkonto an und übernimmt für privilegierte Arbeiten die Rolle root, statt sich als root anzumelden oder per su in ein anonymes, gemeinsam genutztes Konto zu wechseln.

Warum es wichtig ist

Da root eine Rolle ist, lässt sich jede privilegierte Aktion dem namentlichen Benutzer zuordnen, der die Rolle übernommen hat. Genau das ist der Zweck dieses Designs: ein besserer Audit-Trail als mit einem gemeinsamen root-Passwort. sudo ist hier nicht der native Mechanismus – die Solaris-eigenen Werkzeuge (pfexec, Rollen, su in eine Rolle) sind älter und übernehmen dessen Aufgabe. Solaris 11.4 liefert sudo zwar mit (Paket security/sudo), und auf vielen Installationen ist es vorhanden, wobei dem bei der Installation angelegten ersten Benutzer Rechte in /etc/sudoers.d/ eingeräumt werden. Ob es installiert ist und was der aufrufende Benutzer damit ausführen darf, unterscheidet sich jedoch von Host zu Host; es lässt sich daher nicht voraussetzen.

So wird es angewendet

• Für gemeinsame Administrationsaufgaben eine Rolle statt eines normalen Login-Kontos anlegen: roleadd -c "description" -P "<profile>" <rolename>, das Passwort mit passwd <rolename> setzen und die Rolle mit usermod -R +<rolename> <user> zuweisen (-R <rolename> ohne + ersetzt die gesamte Rollenliste des Benutzers). Mit einer Rolle ist keine direkte Anmeldung möglich; roles <user> und profiles <user> zeigen an, was einem Benutzer zugewiesen ist.
• Einen einzelnen privilegierten Befehl ohne dauerhafte Rollen-Shell ausführen: pfexec <command>. pfexec setzt das Prozess-Flag für die Profil-Shell und führt den Befehl ausschliesslich mit den Rechten der Profile aus, die dem aufrufenden Benutzer selbst zugewiesen sind – nicht mit denen einer Rolle, die er übernehmen könnte. Bei Befehlen in einem authentifizierten Rechteprofil wird zuerst das Passwort des Benutzers abgefragt.
• Bevor vom Standard ausgegangen wird, prüfen, ob root auf dem jeweiligen Host aktuell eine Rolle oder ein Benutzer ist: userattr type root gibt bei einer Rolle role aus, bei einem Benutzer nichts oder normal. Solaris erlaubt es, dies in beide Richtungen umzustellen: mit usermod -K type=role root (zur Rolle machen) oder rolemod -K type=normal root (wieder zu einem direkt anmeldbaren Benutzer machen). Bevor root zur Rolle gemacht wird, die Rolle mindestens einem namentlichen Benutzer zuweisen (usermod -R +root <user>) und su root von diesem Konto aus in einer zweiten Sitzung testen; andernfalls kann niemand mehr über das Netzwerk root werden.
• Für unbeaufsichtigt laufende Skripte dem Konto, unter dem das Skript läuft, ein eng gefasstes Rechteprofil zuweisen und die privilegierten Befehle über pfexec aufrufen. Eine Rolle erfordert su und ihr Passwort, was sich für den unbeaufsichtigten Betrieb nicht eignet.

Stolpersteine

• Annehmen, dass auf einem Solaris-11.4-Host sudo verfügbar und für den eigenen Benutzer konfiguriert ist. Vor dem Schreiben von Automatisierung, die es aufruft, mit command -v sudo und sudo -n -l prüfen.
• Erwarten, dass pfexec die Rechte einer Rolle nutzt: Ein Benutzer, dem die Rolle root, aber kein passendes Profil zugewiesen ist, erhält durch pfexec keine zusätzlichen Rechte. Er muss die Rolle mit su root (oder su <rolename>) übernehmen – ein separater, protokollierter Schritt.