Dzięki modularnej budowie, te same moduły mogą być wykorzystywane do ochrony różnego rodzaju zasobów.
Rysunek 1. Idea PAM.
Źródło rysunku: http://docs.oracle.com/cd/E19963-01/html/819-2145/pam-01.html
Modernizacja mechanizmów ochrony może się odbywać poprzez instalację modułu. Ten sam moduł może być wykorzystany w różnych programach.
Szczegóły opisano w dokumencie OSF RFC 86.0. "Unified Login with Pluggable Authentication Modules (PAM)"
Moduły
Spis często spotykanych modułów PAM [zob.:http://students.mimuw.edu.pl/SO/Projekt02-03/temat4-g6/bernatowicz/pam.htm ]:
Moduły standardowe
-
pam_cracklib eliminuje słabe hasła
-
pam_deny realizuje odmowę dostępu
-
pam_ftp obsługuje anonimowe ftp
-
pam_group przydziela do grup użytkowników
-
pam_limits ogranicza dostęp na podstawie dostępnych zasobów
-
pam_listfile reguluje dostęp na podstawie list użytkowników
-
pam_tally realizuje odmowę dostępu w zależności od liczby nieudanych logowań
-
pam_unix realizuje standardowe uniksowe zarządzanie autentykacją
-
pam_warn moduł logujący informacje do syslog
Moduły dodatkowe
-
mod_auth_pam moduł autentykujący dla serwera Apache, są również inne spełniające podobne funkcje
-
pam_smb grupa modułów współpracujących z serwerem Samba
-
pam_mysql autentykacja na podstawie bazy danych MySQL
-
pam_ldap współpraca z serwisem LDAP
-
pam_proftpd autentykacja dla serwera ProFtpd
-
pam_nw_auth współpraca z siecią Netware, również NDS
Moduł pam_unix realizuje wszystkie funkcje związane z tradycyjnym modelem autentykacji w Uniksie, opartym na pliku /etc/passwd. Dzięki niemu można skonfigurować system używający PAM tak, aby naśladował działanie systemu haseł Uniksa.
Moduły dodatkowe umożliwiają wprowadzenie rozproszonego systemu autentykacji wykorzystującego sieć komputerową. Dostępne są moduły umożliwiające połączenia z siecią opartą na serwisach LDAP, NDS czy Samba.
Konfiguracja PAM
Konfiguracja PAM dla systemu Linux zawarta jest w katalogu /etc/pam.d. Każda usługa jest opisana w odrębnym pliku. Na przykład konfiguracja logowania do serwera poczty celem jej odczytania (protokół pop3) zawarta jest w pliku /etc/pam.d/pop3. (W niektórych starszych dystrybucjach jest to wspólny plik /etc/pam.conf ). Każdy plik zawiera wiersze definiujące wykorzystanie jednego modułu PAM dla danej usługi. Składnia wiersza:
[module-type] [control-flag] [module-path] [arguments]
gdzie:
-
module-type – typ modułu ,
-
control-flag - reakcja na wynik zwrócony przez moduł,
-
module-path - pełna ścieżka do modułu,
-
arguments - opcjonalne parametry dla modułu, przekazywane mu przez linię poleceń.
Jeśli konfiguracja jest w jednym pliku (pam.conf), to dodatkowo w pierwszej kolumnie znajduje się nazwa usługi, której dany wiersz dotyczy. Szczegółowe wyjaśnienie poniżej.
module-type – typ modułu
Jedna z typów modułów (auth, account, session, password), pokazanych na poniższym rysunku:
Rysunek 2. Struktura PAM
źródło rysunku: Grzegorz Jacek Nalepa: Wykorzystanie systemu PAM w GNU/Linuksie
Typy modułów:
-
auth - autentykacja (authentication management).
Identyfikacja użytkownika – na przykład na podstawie hasła. Ewentualne przypisanie użytkownika do odpowiedniej grupy.
-
account - konto (account management)
Ustalenie uprawnień zidentyfikowanego użytkownika. Mogą być brane pod uwagę różne czynniki – jak dostępne zasoby systemu, pora dnia, czy lokalizacja użytkownika.
-
session - sesja (session management)
Działania przed otwarciem lub zamknięciem sesji użytkownika, takie jak rejestrowanie informacji o użytkowniku, modyfikacje środowiska lub montowanie odpowiednich systemów plików.
-
password - hasła (password management)
Uaktualnianie bazy użytkowników, zawierających ich hasła, dane osobowe, czy listy uprawnień.
control-flag - reakcja na wynik zwrócony przez moduł
W praktyce jednak stosuje się uproszczony (starszy) sposób określania tego parametru, który polega na podaniu jednej z następujących wartości [cyt. za: http://kursy24.eu/linux/view/item/pam]:
-
required – moduł z tą flagą musi być wykonany pomyślnie, aby cały proces uwierzytelniania zakończył się pozytywnie. Niezależnie od powodzenia wykonania modułu, pozostałe moduły zawsze są wykonywane do końca – zapobiega to wykryciu miejsca potencjalnego niepowodzenia procesu uwierzytelnienia.
-
requisite – moduł z tą flagą musi być wykonany pomyślnie, aby cały proces uwierzytelniania zakończył się pozytywnie. W przypadku pozytywnego wykonania modułu, pozostałe moduły wykonywane są do końca, jednak w przypadku niepowodzenia, użytkownik od razu dostaje informację zwrotną, że proces uwierzytelnienia się nie powiódł.
-
optional – powodzenie wykonania modułu nie ma znaczenia dla pomyślności całego procesu uwierzytelnienia. Zwykle stosowany tylko do wyświetlania informacji np. że przyszła nowa poczta.
-
sufficient – pozytywne zakończenie modułu powoduje przekazanie informacji zwrotnej o pomyślnym przeprowadzeniu procesu uwierzytelnienia (pod warunkiem, że wcześniej nie było niepowodzenia przy module z flagą required). Negatywne zakończenie modułu nie ma wpływu na dalszy przebieg procesu uwierzytelnienia – pozostałe moduły są dalej wykonywane jakby nic się nie stało.
-
include – nie jest to flaga kontrolna, ale określa, że należy zaimportować i wykonać plik o nazwie określonej przez następny parametr, czyli module-path (zob. poniżej przykład).
Nowsza składnia dla tego parametru wygląda następująco (zob. link):
[wartość1=działanie1 wartość2=działanie2 ...]
gdzie:
- wartośćn - jedna z wartości zwracanych przez moduł, na przykład: success, open_err.
- działanien: działanie, jakie biblioteka ma podjąć po otrzymaniu kodu o podanej wartości; jest to jedna z wartości: ignore, bad, die, ok, done, reset.
module-path - pełna ścieżka do modułu,
Najczęściej moduły są zapisane w katalogu: /lib/security/*.so. A więc pełna ścieżka do modułu ma format: /lib/security/<nazwa modułu>.so.
arguments - opcjonalne parametry dla modułu
Istnieje grupa argumentów standardowych, które powinny przyjmować wszystkie moduły: debug, no_warn, use_first_pass, try_first_pass, expose_account. Ponadto mogą występować różne parametry indywidualne dla różnych modułów.
Przykład
Login – na podstawie RFC-86:
service module_type control_flag module_path options
------- ----------- ------------ ----------- -------
login auth required pam_unix_auth.so nowarn
login session required pam_unix_session.so
login account required pam_unix_account.so
ftp auth required pam_skey_auth.so debug
ftp session required pam_unix_session.so
telnet session required pam_unix_session.so
login password required pam_unix_passwd.so
passwd password required pam_unix_passwd.so
OTHER auth required pam_unix_auth.so
OTHER session required pam_unix_session.so
OTHER account required pam_unix_account.so
Na koniec kursu opublikowanego na stronie kursy24.eu znajdują się przykłady, które pomagają samodzielnie przećwiczyć konfigurowanie PAM.