Centralna autentykacja - reguły sudo w IPA

Red Hat 6.x / CentOS 6.x

Centralna autentykacja pozwala nam z jednego miejsca zarządzać dostępami dla użytkowników. Oczywistym rozszerzeniem możliwości kontrolowania samych dostępów dla użytkowników jest zarządzanie ich rozszerzonymi uprawnieniami sudo.

Ipa oferuje możliwość definiowania reguł sudo dla użytkowników czy grup użytkowników i zaaplikowanie ich na konkretny host lub grupę hostów. Samo konfigurowanie reguł można przeprowadzić przez webowy panel administracyjny IPA (dla leniwych), lub poprzez shella (dla ambitnych). U mnie lenistwo przewyższa ambicję ;).

Aby rozwiązanie to mogło być wykorzystane konieczna będzie dodatkowa konfiguracja zarówno po stronie serwera IPA jak i hosta-klienta.

Konfiguracja serwerów do używania zdalnych plików sudoers

Pierwszym krokiem jaki musimy wykonać (jednorazowo dla każdej domeny ipa) jest zdefiniowanie hasła dla użytkownika sudo. Jako, że definicje użytkownika rezydują w ldap-ie, użyjemy komendy ldappasswd:

[root@server ipa]# ldappasswd -Y GSSAPI -S -h server.ipa.local uid=sudo,cn=sysaccounts,cn=etc,dc=ipa,dc=local
New password: {haslo_sudo}
Re-enter new password: {haslo_sudo}
SASL/GSSAPI authentication started
SASL username: admin@IPA.LOCAL
SASL SSF: 56
SASL data security layer installed.

Credentiali tych używać będziemy do konfiguracji autentykacji na wszystkich hostach klienckich. Przejdźmy zatem do ich konfiguracji (tą powtarzamy na wszystkich maszynach korzystających z logowania poprzez IPA).

W pierwszej kolejności musimy odblokować możliwość korzystania przez system ze zdalnego sudoers. Odbywa się to przez edycję pliku /etc/nsswitch.conf, a dokładniej dodanie ldap do definicji sudoers:

[root@ipaclient1 ipa]# vi /etc/nsswitch.conf
...
sudoers: files ldap sss
...

Kolejnym krokiem będzie konfiguracja samego ldap-a z którego sudo ma korzystać:

[root@ipaclient1 ipa]# vi /etc/sudo-ldap.conf
 
binddn uid=sudo,cn=sysaccounts,cn=etc,dc=ipa,dc=local
bindpw 1qazXSW@
ssl start_tls
tls_cacertfile /etc/ipa/ca.crt
tls_checkpeer yes
uri ldap://server.ipa.local
sudoers_base ou=SUDOers,dc=ipa,dc=local
bind_timelimit 30
timelimit 30

Powyższe linie należy odkomentować i zmodyfikować (elementy wymagające modyfikacji zaznaczyłem na żółto). bindpw to hasło, które ustawialiśmy wcześniej dla sudo. Pozostałe pozycje są raczej oczywiste.

Pozostaje nam jeszcze definicja domeny NIS - zalecana przez Red Hat, choć całość w podstawowej wersji działa również bez tego:

[root@ipaclient1 ipa]# vi /etc/rc.d/rc.local
...
nisdomainname ipa.local
...

Jako, że dane są w zasadzie stałe dla wszystkich maszyn-klientów, w prosty sposób możemy oskryptować te działania, ułatwiając sobie pracę.

Definiowanie reguł sudo poprzez panel www IPA

Całością konfiguracji sudo od strony panelu administracyjnego IPA zarządzamy w zasadzie poprzez trzy zakładki umieszczone w Policy > Sudo:

Definiowanie reguł sudo rozpoczynamy od określenia komendy jaka ma być przez taką regułę obsługiwana:

Definicja ta zawierać musi pełną komendę jaką użytkownik będzie mógł wykonać poprzez sudo, np /bin/cat /etc/shadow. Ważne jest, żeby poszczególne komendy (jak w tym wypadku cat) podawać z pełną ścieżką w systemie, gdyż inaczej sudo może nie zadziałać.

TIP: Jeśli nie wiesz w jakiej lokalizacji znajduje się dana binarka możesz użyć polecenia which komenda.

Kolejnym poziomem - opcjonalnym - mogą być grupy sudo. Możemy tu zebrać w jeden kontener kilka zdefiniowanych komend, aby posługiwać się nimi podczas tworzenia reguł. Podczas tworzenia grupy definiujemy jedynie jej nazwę, a po utworzeniu uzupełniamy o komendy, które chcemy w grupie umieścić.

Ostatnim poziomem jest utworzenie właściwej reguły sudo, która precyzuje komendy, użytkowników oraz hosty, na których ma działać.
Sudo rules > Dodaj wywoła proste okno, w którym zdefiniujemy nazwę reguły. Warto w nazwie zawierać możliwie dużo zwięzłych informacji, aby przy wielu regułach nie mieć problemów z ich identyfikacją, np:

Po zdefiniowaniu możemy przejść do ustawień reguły, poprzez kliknięcie na jej nazwę. Konfiguracja odbywa się na jednej stronie posegregowanej w kilka sekcji:

* General - opis reguły
* Options - opcje komendy sudo
* Who - definicje użytkowników uprawnionych do korzystania z reguły
* Access this host - definicje hostów na których reguła ma działać
* Run commands - komendy które mogą być uruchamiane w ramach reguły
* As whom - z uprawnieniami jakiego usera komenda ma być wykonana (domyśnie jest to root).

Wszystkie sekcje poza Options umożliwiają wybranie zdefiniowanych wcześniej pozycji, np. hostów, grup hostów, użytkowników, komend itd. Wszystkie z nich mają również checkbox "Any", umożliwiający wybranie wszystkich możliwości z danej sekcji (poniżej na żółto). Ja zgodnie z nazwą skonfigurowałem regułę, aby na wszystkich hostach pozwalała wykonać cat na /etc/shadow:

Jak widać uprawnienia do reguły posiada jedynie user test1.

Ważnym elementem definicji reguł są opcje sudo, które możemy uwzględniać w każdej z nich z osobna. Wszystkie opcje opisane są na stronie manuala sudo choć mało która jest używana często.

Do używanych najczęściej bez wątpienia należy odpowiednik "NOPASSWD" z tradycyjnego pliku /etc/sudoers, czyli !authenticate. Opcja pozwala wykonywać użytkownikowi sudo nie wymagając od niego żadnej dodatkowej autoryzacji:

Po tych definicjach możemy zweryfikować działanie naszej reguły logując się na dowolny host jako user test1 i porównując działania komendy z oraz bez sudo:

[root@ipaclient1 ipa]# su test1
sh-4.1$ cat /etc/shadow
cat: /etc/shadow: Permission denied
sh-4.1$ sudo cat /etc/shadow
root:$6$12o5DXryNHU2IFiH$NzNc/EU8SonPDxDNHFDjbdK6JCVMoaGd99BJ8L9xz6mRyiLkCkY4cPNpDWgvc91aXgcwHzDN4e9WKEIH3XCAs.:16671:0:99999:7:::
bin:*:15980:0:99999:7:::
daemon:*:15980:0:99999:7:::
adm:*:15980:0:99999:7:::
lp:*:15980:0:99999:7:::
sync:*:15980:0:99999:7:::
shutdown:*:15980:0:99999:7:::
halt:*:15980:0:99999:7:::
...

Użytkownik będąc zalogowanym na serwerze może zweryfikować swoje upranienia sudo w zwyczajny sposób, tj. poprzez sudo -l.

Jedną z koniecznych reguł będzie dla każdego administratora uzyskanie pełnego dostępu do własnych systemów. W IPA osobne omawianie tematu nie jest chyba konieczne. Po prostu zdefiniuj komendę jako Any Command, nie zapomnij o !authenticate i dobrej nazwie, np: