Pluggable authentication modules (PAM) - składnia i konfiguracja

Red Hat 6.x / CentOS 6.x

PAM to mechanizm wykorzystywany przez aplikacje do weryfikacji autentykacji wykonywanych przez nie w systemie działań.

PAM przechowuje swoje pliki konfiguracyjne w kilku miejscach w systemie. Spora część konfiguracji umieszczona jest w plikach z katalogu /etc/pam.d. Domyślnie aplikacje posiadają własne pliki konfiguracji PAM umieszczone w tym katalogu, ale mogą również pośrednio korzystać z konfiguracji zawartej w innych plikach. Kolejna część konfiguracji znajduje się w katalogu /etc/security.

Konfiguracja /etc/pam.d

Pliki konfiguracyjne posiadają charakterystyczną składnię, dzielącą proces autentykacyjny aplikacji na cztery różne typy (rule types). W każdym z typów może występować sześć różnych kontrolek definiujących zachowania dla danego wpisu (PAM controls).

Możliwymi do konfiguracji typami są:
* auth - definicje tego typu są weryfikowane podczas autoryzacji aplikacji w systemie
* account - reguły weryfikujące właściwości konta użytkownika, jak np. czy konto nie wyekspirowało, czy pliki konfiguracyjne wymagane do utrzymania sesji są na miejscu itp.
* password - definiuje zachowanie się aplikacji, kiedy użytkownik próbuje zmienić własne hasło przy jej użyciu.
* session - definiują inne zachowania w obrębie sesji użytkownika lub aplikacji, jak np zapisywanie informacji do logów, wczytywanie reguł selinuxa czy dostępy do urządzeń.

Kontrolki występujące w konfiguracji:
* required - pozytywne przejście tej reguły jest wymagane, aby uzyskać autentykację w danej aplikacji. Bez względu na wynik system przeprowadzi weryfikację pozostałych reguł, a użytkownik zostanie poniformowany o błędzie po ich przejściu.
* requisite - opcja podobna do required - wymagana do pozytywnego przejścia, jednak w przypadku błędnego wyniku reguła spowoduje przekazanie kontroli do aplikacji bez weryfikacji pozostałych reguł.
* sufficient - reguła, której przejście nie musi zakończyć się sukcesem, ale jeśli tak się stanie, i poprzedzające ją reguły required nie zwróciły błędu, żadna kolejna reguła danego typu nie będzie sprawdzana i zostanie wykonana autoryzacja.
* optional - wynik weryfikacji danej reguły nie ma wpływu na przebieg weryfikacji autoryzacji danego typu, chyba, że nie występują inne reguły danego typu.
* include - reguła dołączająca wpisy konfiguracyjne danego typu z innego pliku. Weryfikacja reguł z dołączonego pliku determinuje sukces lub błąd reguły include.
* substack - opcja podobna do include z jedną zasadniczą różnicą. W przypadku niepowodzenia weryfikacji jednej z opcji załączonej w ten sposób zakończy weryfikację innych reguł w dołączonym pliku, a proces przejdzie do kolejnej reguły z pliku głównego.

Składnia reguł umieszczonych w plikach wygląda następująco:

typ        kontrolka    nazwa_modułu    opcje_modułu

 Moduł w rzeczywistości jest biblioteką pam, która w zależności od systemu powinna znajdować się w lokalizacji /lib/security lub /lib64/security. Opcje modułu, jeśli takie wystąpią znajdziemy w większości przypadków dość dobrze opisane w manualu danego modułu.

Tyle suchej teorii, która nie wygląda zbyt zrozumiale, dlatego dla przykładu przeanalizujmy jedną z istniejących w systemie konfiguracji, np: /etc/pam.d/su. Zawartość pliku przedstawia się następująco:

[root@ipaclient1 security]# cat /etc/pam.d/su
#%PAM-1.0
auth            sufficient      pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth           sufficient      pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
#auth           required        pam_wheel.so use_uid
auth            include         system-auth
account         sufficient      pam_succeed_if.so uid = 0 use_uid quiet
account         include         system-auth
password        include         system-auth
session         include         system-auth
session         optional        pam_xauth.so

Jak widać program su ma zdefiniowane reguły dla wszystkich rule types. W naszym śledzeniu skupimy się na jednym, a mianowicie auth.

Typ auth, jako wystarczające do autentykacji (sufficient) podaje poprawne przejście modułu pam_rootok.so. Moduł ten autentykuje użytkownika, jeśli ten jest rootem (id=0), i faktycznie dla su ten warunek autoryzacji jest spełniany (root zawsze może zrobić su). W przypadku, kiedy użytkownik nie jest rootem kolejna reguła definiuje, iż do autoryzacji będzie dołączony plik system-auth. Zerknijmy zatem w reguły typu auth zawarte w tym pliku:

[root@ipaclient1 security]# cat /etc/pam.d/system-auth | grep ^auth
auth        required      pam_env.so
auth        sufficient    pam_fprintd.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_sss.so use_first_pass
auth        required      pam_deny.so

W pierwszej kolejności moduł próbuje ustawić zmienne środowiskowe (pam_env). Kolejnym elementem jest moduł pam_fprintd, który w środowisku graficznym odpowiada za czasowe przetrzymywanie (cacheowanie) danych użytkonika root w sesji (fingerprint daemon) i nie jest on wykorzystywany w wersji tekstowej systemu. Jeśli nie mamy zcacheowanych credentiali roota przechodzimy do reguły wywołującej pam_unix.so, który to moduł odpowiada za tradycyjną autoryzację hasłem - jeśli autoryzacja ta przebiegnie pomyślnie to reguła, jako wystarczająca zautoryzuje nas do wykonania aplikacji su. Jeśli poprzednie reguły sufficient nie zakończą się sukcesem zostanie zweryfikowany uid użytkownika. Moduł pam_succeed_if sprawdzi, czy nasz użytkownik ma uid większe niż 500 (nie jest usługą systemową) - jeśli tak nie będzie, zwróci błąd autoryzacji. Po poprawnej weryfikacji id usera spróbujemy uzyskać autentykację za pomocą usługi SSSd (System Security Services daemon), która odpowiada za zdalną autentykację, np z LDAP-a, AD czy kerberosa.
Jeśli ten moduł nie zautentykuje nas, wykonany zostanie pam_deny, czyli system odmówi autentykacji dla aplikacji su.

Taką analizę można przeprowadzić samemu dla każdego z plików i każdego typu. Bardzo przydatne do tego będą manuale modułów.

Konfiguracja /etc/security

Pliki zawarte w tym katalogu przypominają bardziej klasyczne pliki konfiguracyjne spotykane w systemach linuksowych. Wszystkie z nich zawierają opis i przykładowe użycia w samym pliku, ale również manuale dokładniej opisujące ich przeznaczenie.
Sama składnia nie jest tak usystematyzowana jak w przypadku modułowych pam.d, ale nie jest również nietypowa, dlatego nie powinna wymagać dodatkowych wyjaśnień. W późniejszym czasie pojawi się tekst z kilkoma przykładowymi zmianami, które mogą okazać się przydatne w pracy administratora.

Kilka uwag na koniec

PAM jest bardzo istotnym dla poprawnego działania systemu mechanizmem, dlatego przy jakiejkolwiek ingerencji zalecana jest ostrożność. Warto, przed edycją plików wykonać ich kopię zapasową, a podczas wprowadzania zmian zawsze zapewnić sobie dodatkowe okienko z aktywną sesją roota. Błąd składniowy w niektórych modułach, lub usunięcie plików konfiguracyjnych może spowodować konieczność odzyskiwania konfiguracji z backupu lub rzeźbę w rescue mode.

W przypadku zabawy z pam.d nieocenionym narzędziem okazuje się man -k, a dokładniej man -k pam, któy pozwoli nam przejrzeć wszystkie moduły dostępne dla pam-a.

PS. Tyle suchej teorii, mało atrakcyjnej i raczej słabo przyswajalnej bez konkretnych przykładów zastosowań. W kolejnych tekstach przejdziemy do konfiguracji konkretnych modułów i zaczniemy wykorzystywać możliwości, jakie PAM nam daje. Będzie o wiele ciekawiej.... (mam nadzieję).