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:

  1. auth - autentykacja (authentication management).

    Identyfikacja użytkownika – na przykład na podstawie hasła. Ewentualne przypisanie użytkownika do odpowiedniej grupy.

  2. 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.

  3. 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.

  4. 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.

Ostatnia modyfikacja: wtorek, 27 listopada 2012, 23:40