Pluggable authentication modules (PAM) - rejestrowanie poczynań użytkowników - pam_tty_audit

Red Hat 6.x / CentOS 6.x

Ciekawym modułem PAM pozwalającym rejestrować poczynania użytkownika w sposób wręcz paranoiczny jest pam_tty_audit.

Moduł konfigurujemy poprzez określenie jako opcji loginu lub loginów użytkowników których chemy śledzić. Działa on jedynie dla typu session, i w taki sposób go skonfigurujemy.

Konfiguracja odbywa się w znanych już plikach /etc/pam.d/system-auth oraz /etc/pam.d/password-auth:

session     optional      pam_keyinit.so revoke
session     required      pam_tty_audit.so enable=test,test2
session     required      pam_limits.so

Przytoczony powyżej przykład spowoduje logowanie działań użytkowników test oraz test2.

Do dyspozycji posiadamy opcje konfiguracyjne:
* enable= - określa oddzielone przecinkiem loginy użytkowników, których chcemy śledzić. Możliwe jest użycie wildcarda * definiującego wszystkich userów w systemie.
* disable= - loginy użytkowników, których śledzić nie chcemy
* log_passwd - standardowo nie są logowane wpisywane przez użytkownika hasła - tą opcją możemy ten stan zmienić

Kolejność wystąpienia opcji enable i disable jest istotna i determinuje zachowanie modułu. Należy pamiętać, że są parsowane w kolejności podania, a każda z nich nadpisuje listę użytkowników z poprzedniej. Inne zatem działanie będzie miała składnia enable=* disable=root logując wszystkich poza rootem, a inne disable=root enable=* logując wszystkich bez wyjątku.

Do przeglądania zalogowanych zdarzeń używać będziemy narzędzia dedykowanego do generowania raportów audytowych z usługi auditd, a mianowicie aureport. Zastosowanie opcji -i powoduje "interpretację" uid usera, czyli jego podmianę na nazwę użytkownika.

[root@server pam.d]# aureport --tty -i

TTY Report
===============================================
# date time event auid term sess comm data
===============================================
1. 10/07/2015 17:26:09 2480 test ? 331 bash <ret>,<ret>,<ret>,"ll",<ret>,"csd /.",<backspace>,<backspace>,<backspace>,<backspace>,<backspace>,"d /tmp",<ret>,"ll",<ret>,"cd o",<tab>,<ret>,"ll",<ret>,<up>,<up>,<tab>,<tab>,"g",<tab>,<ret>,"l",<backspace>,<^D>
2. 10/07/2015 18:46:47 2576 test ? 341 less "q"
3. 10/07/2015 18:46:48 2577 test ? 341 bash "test",<ret>,"man test",<ret>,<^D>
4. 10/07/2015 19:02:43 2699 test ? 348 bash "ll",<ret>,"touch test",<ret>,<^D>
5. 10/07/2015 19:02:57 2725 test2 ? 349 bash "ll",<ret>,"pwd",<ret>,"touch test",<ret>,<^D>

Jak widać na przykładzie logowanie jest bardzo dokładne i w podstawowej opcji obejmuje niciśnięcie przez użytkownika każdego klawisza, jeśli wpisywane znaki nie są częścią hasła.

Pluggable authentication modules (PAM) - dodatkowa konfiguracja modułów /etc/security

Red Hat 6.x / CentOS 6.x

Poza konfiguracją działania modułów w plikach /etc/pam.d, mechanizm PAM używa również konfiguracji zawartej w plikach znajdujących się w katalogu /etc/security. Konfiguracje te są aplikowane globalnie do odpowiadających im nazwą modułów. Działanie i przykłady użycia konfiguracji są opisane w samych plikach, oraz we właściwych manualach systemowych.

Najczęściej używanymi są access.conf oraz limits.conf, i to na nich skupię ten tekst.

Konfiguracja limitów systemowych - limits.conf

Przy użyciu tego pliku możemy zdefiniować kilka limitów systemowych dla użytkowników lub ich grup. Jak opisuje to sam plik limits.conf składnia konfiguracji wygląda następująco:

<domain>        <type>  <item>  <value>

Opis poszczególnych pól w pliku jest czytelny:
* domain - może to być użytkownik, grupa użytkowników jeśli wpis poprzedzony będzie @, lub wildcard-y % i * oznaczający wartość domyślną
* type to typ limitu - soft lub hard. Limitu hard system nie pozwoli przekroczyć, limit soft w niektórych orzypadkach może zostać przekroczony, ale zostaniemy poinformowani o tym fakcie.
* item to element, który zamierzamy limitować - wszystkie możliwości wymienione są w pliku.
* value to oczywiście wartość limitu.

Dla przykładu zdefiniujemy sobie limit jednoczesnych logowań konkretnego użytkownika. W pliku limits.conf dodajmy następującą linię:

test    hard    maxlogins 1

Nawiązanie pierwszej sesji użytkownika test przebiega normalnie, ale przy próbie nawiązania kolejnej otrzymamy komunikat:

[root@ipaclient1 ~]# ssh test@192.168.1.110
test@192.168.1.110's password:
Too many logins for 'test'.
Last login: Sat Oct  3 13:04:46 2015 from 192.168.1.111
Connection to 192.168.1.110 closed.

Kontrola dostępu poprzez access.conf

Z użyciem pliku access.conf w prosty sposób możemy ograniczyć dostęp konkretnych użytkowników z nieautoryzowanych lokalizacji, np. podsieci IP czy terminali. Sam plik konfiguracyjny pełen jest przykładów, które wystarczy dostosować do własnych potrzeb, np dodanie wpisu:

+ : test : 192.168.1.111
- : test : ALL

przydzieli dostęp (+) dla użytkownika test z jednego adresu IP (192.168.1.111) - próby zalogowania się z innych lokalizacji (ALL) zakończą się niepowodzeniem (ograniczenie dostępu poprzez -).

Należy pamiętać o jednej rzeczy. Z konfiguracji zawartej w tym pliku korzysta moduł pam_access.so, który nie jest domyślnie ładowany przez PAM - dlatego należy go dodać w plikach /etc/pam.d/password-auth oraz /etc/pam.d/system-auth:

auth        required      pam_env.so
auth        required      pam_access.so
auth        sufficient    pam_fprintd.so

Pluggable authentication modules (PAM) - blokowanie użytkowników po nieudanej próbie logowania - pam_tally2

Red Hat 6.x / CentOS 6.x

Moduł pam_tally2 to swoisty licznik nieudanych logowań użytkowników do systemu. Działanie to pozwala nam wykrywać próby złamania hasła usera i włamania na serwer. Poza monitorowaniem prób pam_tally2 pozwala nam również proaktywnie na nie odpowiadać np. poprzez blokowanie konta użytkownika dla którego wykryto zbyt dużą ilość nieudanych prób autoryzacji.

Uruchomienie procesu monitorowania logowań

Jak w przypadku wszystkich modułów pam, uruchomienie i tego wymagać będzie dodania go do odpowiedniej sekcji konfiguracji. Jako, że moduł ma nadzorować próby autoryzacji (typ auth) będzie on koniecznym (required) elementem konfiguracji dla wszelkich aplikacji dokonujących autoryzacji użytkownika w systemie, więc dodany musi zostać w plikach /etc/pam.d/system-auth oraz /etc/pam.d/password-auth. Słowem wyjaśnienia password-auth odpowiada za procesy autoryzacyjne przy zdalnym dostępie do systemu (np. ssh), system-auth natomiast za dostęp bezpośredni (np. konsola serwera).

Moduł powinien być uruchamiany przed zautoryzowaniem użytkownika, dlatego wpis należy umieścić przed modułem pam_unix, który jako sufficient po zautoryzowaniu użytkownika nie dopuści do weryfikacji modułów występujących po nim. Dodana linia wyglądać będzie następująco:

auth        required      pam_env.so
auth        required      pam_tally2.so [opcje]
auth        sufficient    pam_unix.so nullok try_first_pass

Opcje modułu

Pełną listę opcji znajdziemy oczywiście w manualu modułu. Najprzydatniejsze w moim wypadku okazały się:

* deny=N, która zablokuje dostęp do konta po N nieudanych próbach logowania. Jeśli w konfiguracji nie zdefiniowaliśmy unlock_time po zablokowaniu konto będzie musiało być odblokowane przez administratora systemu ręcznie.

* lock_time=N - definiuje czas (w sekundach) na jaki dostęp dla konta zostanie zablokowany po nieudanej próbie autoryzacji

* unlock_time=N to czas określony w sekundach, na jaki konto zostanie zablokowane po blokadzie określonej przez deny nieudanych prób logowania.

* even_deny_root spowoduje, że konto roota również będzie blokowane, tak jak zwykłe konto (domyślnie nie jest). Parametr ten używany jest najczęściej z root_unlock_time=N, który definiuje czas po jakim dostęp zostanie odblokowany.

* silent zagwarantuje brak wyświetlania informacji o logowaniu userowi

* file=/sciezka/do/pliku pozwoli nam zdefiniować inny od standardowego var/log/tallylog plik przechowywania informacji o logowaniach.

Dla przykładu zdefiniujmy sobie taką regułę:

auth        required      pam_tally2.so deny=3 lock_time=10 unlock_time=60

Jaki będzie skutek? Moduł zablokuje dostęp do konta na 10 sekund po każdej nieudanej próbie logowania (podaniu błędnego hasła). Po trzech nieudanych próbach (w tym wypadku nieudane próby liczone są co 10 sekund) na 60 sekund zostanie zablokowana możliwość zalogowania się na konto.
System nie informuje użytkownika o powodzie nieudanego logowania i każda próba po blokadzie czasowej konta wygląda, jakby wprowadzane hasło było niepoprawne.

Statystyki nieudanych logowań

Moduł posiada niewielki interfejs pozwalający administratorowi na weryfikację ilości nieudanych logowań oraz czasu i adresu źródłowego wystąpienia ostatniego z nich.

[root@ipaclient1 pam.d]# pam_tally2
Login           Failures Latest failure     From
root                1    10/02/15 17:42:15  server.ipa.local
test                8    10/02/15 17:38:41  server.ipa.local

Jak widać system odnotował 8 nieudanych prób logowania na konto użytkownika test, z czego ostatnie o 17:38:41 z maszyny server.ipa.local, oraz jedną nieudaną próbę logowania na root-a... Wyświetlane wyniki możemy ograniczyć do jednego tylko usera poprzez parametr -u username.

Dzięki interfejsowi możemy dodatkowo zrealizować jeszcze jedno zadanie, mianowicie zresetować licznik nieudanych logowań dla użytkownika. Może to być przydatne w sytuacji, kiedy sami zapomnieliśmy hasła, a nie chcemy zaciemniać statystyk nieautoryzowanych prób logowania poprzez własne nieudane próby.

[root@ipaclient1 pam.d]# pam_tally2 -u test
Login           Failures Latest failure     From
test                8    10/02/15 17:38:41  server.ipa.local
[root@ipaclient1 pam.d]# pam_tally2 --reset=4 -u test
Login           Failures Latest failure     From
test                8    10/02/15 17:38:41  server.ipa.local
[root@ipaclient1 pam.d]# pam_tally2 -u test
Login           Failures Latest failure     From
test                4    10/02/15 17:38:41  server.ipa.local

Możemy również użyć krótkiej opcji -r, która wyzeruje licznik nieudanych logowań, a w przypadku kiedy nie określimy użytkownika, dla którego licznik ma być zresetowany, uwzględnione zostaną wszystkie konta.

[root@ipaclient1 pam.d]# pam_tally2 -r
Login           Failures Latest failure     From
root                1    10/02/15 17:53:17  server.ipa.local
test                1    10/02/15 17:53:40  server.ipa.local
[root@ipaclient1 pam.d]# pam_tally2

Jak widać podczas resetowania liczników pam_tally2 wyświetla ostatni status nieudanych logowań, a następnie je zeruje.

Pluggable authentication modules (PAM) - polityki haseł z wykorzystaniem pam_cracklib

Red Hat 6.x / CentOS 6.x

Teorię konfiguracji modułów PAM poznaliśmy przy okazji tekstu Pluggable authentication modules (PAM) - składnia i konfiguracja, więc czas wykorzystać te informacje w praktyce.

Najpopularnijszym bodaj modułem PAM, a zarazem pierwszym z jakim miałem styczność jest moduł pam_cracklib.so, dzięki któremu możemy w naszym systemie definiować polityki dotyczące wymogów, jakie muszą spełniać hasła użytkowników.

Moduł ten jest domyślnie załadowany do systemu poprzez moduły /etc/pam.d/password-auth oraz /etc/pam.d/system-auth, ale konfiguracja jego jest bardzo uboga:

password    requisite     pam_cracklib.so try_first_pass retry=3 type=

Oznacza to, że pozytywne przejście modułu jest wymagane dla typu password. Jak widzimy moduł jest wywołany z trzema opcjami:
* try_first_pass - ta opcja przed spytaniem użytkownika o hasło sprawdzi, czy wcześniej zastackowane hasło nie będzie wystarczające do autoryzacji. Przy zmianie hasła chyba nie wykorzystywane
* retry=3 - określa ile razy zapytać o hasło przed zwróceniem błędu
* type= funkcja jest aliasem dla authok_type, a odpowiada za wyświetlenie części prompta zmiany hasła. Wartość nie powinna zawierać spacji. Wartość pojawi się w postaci: "New WARTOSC_ZE_ZMIENNEJ_TYPE password:" oraz "Retype new WARTOSC_ZE_ZMIENNEJ_TYPE password:" przy próbue zmiany hasła.

Jak widać, żadna z opcji nie określa warunków, jakie hasło powinno spełniać, dlatego pozwolę sobie wymienić i wdrożyć kilka najprzydatniejszych z nich. Zmiany opcji, aby mieć pewność prawidłowego działania nowych reguł należy wdrożyć w obu plikach, tj: password-auth oraz system-auth.

Opcje weryfikacji wymogów dla haseł

Wszystkich z poniższych opcji możemy używać jednocześnie, umieszczając je po sobie oddzielone spacją.

* difok=N - użycie opcji wymusza ilość znaków, którymi nowo podane hasło musi różnić się od starego hasła (domyślnie jest to 5)

Konfiguracja:

password    requisite     pam_cracklib.so try_first_pass retry=3 type= difok=3

Działanie:

-bash-4.1$ passwd
Changing password for user test.
Changing password for test.
(current) UNIX password:1qaz@WSX
New password:1qaz@WDC
BAD PASSWORD: is too similar to the old one
New password:1qaz#EDC
Retype new password:1qaz#EDC
passwd: all authentication tokens updated successfully.

* lcredit=N
* ucredit=N
* dcredit=N
* ocredit=N

Wymienione powyżej opcje determinują maksymalną ilość tzw. znaków kredytowych w haśle.Znakami tymi są odpowiednio:
     l (lowercase) - małe litery
    u (uppercase) - duże litery
    d (digits) - cyfry
    o (other) - znaki specjalne
Ważną właściwością tych opcji jest to, że określają maksymalną, a nie jak by mogło się wydawać naturalne minimalną ilość znaków danego typu w haśle. Szczęśliwie opcaj przyjmuje wartości ujemne odwracając swoje działanie, dlatego jeśli chcemy zdefiniować minimalną wymaganą ilość znaków danego typu wrtość opcji ustawiamy na wartość ujemną (np. ucredut=-3 spowoduje, że w haśle będą musiały wystąpić conajmniej 3 duże litery). Komunikat o niespełnieniu wymagań nie mówi niestety nic o wymogach jakie podawane hasło powinno spełniać. Dla przykładowej konfiguracji:

password    requisite     pam_cracklib.so try_first_pass retry=3 type= ucredit=-1 dcredit=-2

moduł będzie wymagał minimum 1 dużej litery oraz 2 cyfr. Komunikat przy niepoprawnym haśle będzie mówił:

bash-4.1$ passwd
Changing password for user test.
Changing password for test.
(current) UNIX password:
New password: smallitblog
BAD PASSWORD: is too simple
New password: sma11itBlog
Retype new password:

* minlen=N - określa jakiej minimalnie długości ma być hasło. Na pozór zastosowanie okazuje się być oczywiste i proste, ale.... moim zdaniem jest to najbardziej "skopana" opcja modułu. Czemu? Już odpowiadam. W podstawowej konfiguracji, np:

password    requisite     pam_cracklib.so try_first_pass retry=3 type= minlen=12

bash-4.1$ passwd
Changing password for user test.
Changing password for test.
(current) UNIX password:
New password: tooshort
BAD PASSWORD: is too simple

Jak się okazuje hasło długości 11 znaków, np: smallitblog będzie wystarczające do spełnienia wymagań modułu. Jest to pierwsza z ingerencji samego modułu w wymaganą długość hasła - jeśli w konfiguracji poza definicją samej minlen nie będziemy wymagać kilku klas kredytowych moduł zmniejszy wymaganą długość hasła o 1 w stosunku do zdeklarowanej przez nas.
Kolejna ingerencja w długość dotyczy również znaków kredytowych. Jeśli przy powyższej konfiguracji w naszym haśle uwzględnimy inne niż lcredit klasy kredytowe, to każda z zastosowanych klas skróci nam wymaganą długość hasła o 1, np:
    - hasło smallitblog przejdzie weryfikację dla wymaganej minimalnej długości 12 znaków
    - hasło Smallitblog przejdzie weryfikację dla 13 znaków, gdyż zastosowaliśmy jedną dodatkową klasę - dużą literę
    - hasło Smallitblo6 przejdzie weryfikację dla 14 znaków. Zastosowaliśmy 2 dodatkowe klasy - dużą literę oraz cyfrę
    - hasło Sm@llitblo6 będzie poprawne dla 15 znakowego limitu, gdyż użyliśmy wszystkich klas kredytowych - małej i dużej litery, cyfry oraz znaku specjalnego.

Przy okazji tej opcji trzeba wspomnieć o jeszcze jednej istotnej rzeczy. Cracklib ma hardkodowany drugi limit minimalnej długości 6 znaków dla hasła, który jest sprawdzany bez względu na wartość podaną przez zmienną minlem, więc jeśli chcesz używać haseł krótszych, będziesz musiał całkowicie wyłączyć weryfikację przez cracklib.

* maxrepeat=N - opcja określa maksymalną ilość powtórzeń tego samego znaku w haśle. Domyślnie ma ona wartość 0, czyli nie jest sprawdzana.

password    requisite     pam_cracklib.so try_first_pass retry=3 type= maxrepeat=1

bash-4.1$ passwd
Changing password for user test.
Changing password for test.
(current) UNIX password:
New password: smallitblog
BAD PASSWORD: contains too many same characters consecutively

* minclass=N - przy pomocy tej opcji możemy wymucić na użytkowniku użycie kilku klas znaków, przy czym nie jest brana pod uwaę ilość znaków z danej klasy, a jedynie jej wystąpienie.

password    requisite     pam_cracklib.so try_first_pass retry=3 type= minclass=3

bash-4.1$ passwd
Changing password for user test.
Changing password for test.
(current) UNIX password:
New password: SmallItBlog
BAD PASSWORD: not enough character classes

* reject_username - nie pozwoli w haśle użyć nazwy użytkownika

password    requisite     pam_cracklib.so try_first_pass retry=3 type= reject_username

bash-4.1$ passwd
Changing password for user test.
Changing password for test.
(current) UNIX password:
New password: test123
BAD PASSWORD: it is based on your username

* enforce_for_root - ta opcja wymusi na użytkowniku root spełnienie warunków jakie zdeklarowano dla haseł. Domyślnie root może ustawić dowolne hasło dla dowolnego usera.

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ę).