FreeIPA sudo rules in der Praxis: Kommandos delegieren ohne Root-Passwörter

Kurzüberblick

Teil 6 der Identity-Serie zeigt FreeIPA sudo rules praktisch auf Fedora 44. Ziel ist eine nachvollziehbare Delegation: Ein Operator darf den Status von sshd auf einem definierten Client prüfen, aber keinen Dienst neu starten und kein Benutzer außerhalb der Gruppe erhält diese Berechtigung.

Wichtig: HBAC entscheidet, ob ein Benutzer überhaupt auf einen Host und Dienst zugreifen darf. Sudo entscheidet danach, welche privilegierten Kommandos auf dem Host erlaubt sind. Beides gehört zusammen, ist aber nicht dasselbe.

https://ipa01.example.test/ipa/ui/

FreeIPA Web UI nach Login im Fedora-44-Sudo-Lab. Screenshot aus dem isolierten FreeIPA-C4-Sudo-Lab auf Fedora 44.

Lab-Aufbau

Server:        ipa01.example.test
Client:        client01.example.test
Domain:        example.test
Realm:         EXAMPLE.TEST
Distribution:  Fedora Linux 44
Kernel:        6.19.14-300.fc44.x86_64
SELinux:       Enforcing

Objektmodell

Das Lab nutzt keine lokalen sudoers-Dateien für die fachliche Berechtigung. Die Regel wird zentral in FreeIPA modelliert: Benutzergruppe, Hostgruppe, Sudo Command, Sudo Command Group und Sudo Rule.

ipa group-add ops-sudo-status \
  --desc='Operators allowed to inspect selected service status'
ipa group-add-member ops-sudo-status --users=opsallowed

ipa hostgroup-add linux-clients \
  --desc='Linux clients using central sudo policy'
ipa hostgroup-add-member linux-clients --hosts=client01.example.test

ipa sudocmd-add '/usr/bin/systemctl status sshd'
ipa sudocmdgroup-add service-status-commands \
  --desc='Read-only service status commands'
ipa sudocmdgroup-add-member service-status-commands \
  --sudocmds='/usr/bin/systemctl status sshd'

ipa sudorule-add allow-service-status \
  --desc='Allow status inspection of sshd on Linux clients'
ipa sudorule-add-user allow-service-status --groups=ops-sudo-status
ipa sudorule-add-host allow-service-status --hostgroups=linux-clients
ipa sudorule-add-allow-command allow-service-status \
  --sudocmdgroups=service-status-commands
ipa sudorule-add-runasuser allow-service-status --users=root
ipa sudorule-add-option allow-service-status --sudooption='!authenticate'

https://ipa01.example.test/ipa/ui/

FreeIPA sudo rule allow-service-status mit Benutzergruppe, Hostgruppe, Command Group und RunAs root. Screenshot aus dem isolierten FreeIPA-C4-Sudo-Lab auf Fedora 44.

https://ipa01.example.test/ipa/ui/

FreeIPA Gruppe ops-sudo-status mit berechtigtem Operator. Screenshot aus dem isolierten FreeIPA-C4-Sudo-Lab auf Fedora 44.

https://ipa01.example.test/ipa/ui/

FreeIPA Hostgruppe linux-clients mit client01.example.test. Screenshot aus dem isolierten FreeIPA-C4-Sudo-Lab auf Fedora 44.

https://ipa01.example.test/ipa/ui/

FreeIPA Sudo Command Group service-status-commands. Screenshot aus dem isolierten FreeIPA-C4-Sudo-Lab auf Fedora 44.

Client-Anbindung über SSSD

Damit sudo die zentralen Regeln sieht, muss der Client sudo über SSSD abfragen. Im Lab waren `sudoers: files sss`, der SSSD-sudo-Responder und ein Cache-Refresh Teil der Abnahme.

# /etc/nsswitch.conf
sudoers:    files sss

# /etc/sssd/sssd.conf
[sssd]
services = nss, pam, ssh, sudo

[sudo]

systemctl restart sssd
sss_cache -E

User opsallowed may run the following commands on client01:
    (root) NOPASSWD: /usr/bin/systemctl status sshd

User opsdenied is not allowed to run sudo on client01.

Positiver Test

Der Benutzer opsallowed ist Mitglied von ops-sudo-status. `sudo -l` zeigt nur das erlaubte Kommando. Mit `SYSTEMD_PAGER=cat` wird der systemd-Status nicht interaktiv ausgegeben und der Test bleibt skriptfähig.

uid=289600003(opsallowed) gid=289600003(opsallowed) groups=289600003(opsallowed),289600005(ops-sudo-status)

User opsallowed may run the following commands on client01:
    (root) NOPASSWD: /usr/bin/systemctl status sshd

SYSTEMD_PAGER=cat sudo -n /usr/bin/systemctl status sshd
Active: active (running)
rc=0

Negative Tests

opsallowed darf den Dienststatus lesen, aber nicht `systemctl restart sshd` ausführen. opsdenied ist als IPA-Benutzer auflösbar, hat aber keine sudo-Berechtigung aus der FreeIPA-Regel.

sudo -n /usr/bin/systemctl restart sshd
sudo: a password is required
restart_rc=1

uid=289600004(opsdenied) gid=289600004(opsdenied) groups=289600004(opsdenied)
SYSTEMD_PAGER=cat sudo -n /usr/bin/systemctl status sshd
sudo: a password is required
denied_user_rc=1

Ergebniskontrolle

Praxisnotizen

• `!authenticate` entspricht im Ergebnis NOPASSWD und sollte nur dort verwendet werden, wo der operative Nutzen und das Risiko dokumentiert sind.

• Nach Regeländerungen können SSSD-Cache und sudo-Refresh-Zeitpunkte sichtbar werden. Für Tests ist `sss_cache -E` plus SSSD-Neustart sinnvoll, produktiv sollte man Cache-Verhalten bewusst planen.

• Für produktive Rollen sollte man Kommandos möglichst eng schneiden und keine pauschalen Root-Rechte über Gruppen verteilen.