(Pluggable Authentication Modules). Wyjaśnienie technologii.

Transkrypt

1 Bezpieczeństwo systemów komputerowych. Temat seminarium: Moduły PAM (Pluggable Authentication Modules). Wyjaśnienie technologii Autor: Bartosz Hetmański Moduły PAM (Pluggable Authentication Modules). Wyjaśnienie technologii. 1

2 Plan prezentacji Co to jest PAM? architektura cel implementacji PAM Konfiguracja pliki konfiguracyjne funkcje grupowanie modułów mapowanie haseł domyślna polityka Podsumowanie 2

3 Co to jest PAM? Dynamiczne moduły uwierzytelniające ang. Pluggable Authentication Modules (PAM) to zestaw bibliotek współdzielonych, które umożliwiają administratorowi systemu wybór spobu w jaki aplikacje uwierzytelniają urzytkowników [7] 3

4 Sytuacja przed PAM Każdy program we własnym kodzie implementuje uwierzytelnianie 4

5 Wady starego podejścia wszystkie aspekty związane z usługami dostępu do systemu (uwierzytelnianie, zarządzanie kontem, sesją i hasłami) zaszyte w kodzie aplikacji kłopot z integracją wielu usług uwierzytelniających oraz dodawaniem nowych różne aplikacje mogą mieć różne wymagania co do uwierzytelniania 5

6 Architektura PAM 6

7 Architektura PAM podstawowy komponent interfejs programisty biblioteki uwierzytelniającej (PAM API) aplikacja żądająca uwierzytelnienia korzysta z API PAM PAM API ładuje odpowiedni moduł, zgodnie z ustawieniami w pliku konfiguracyjnym żądanie klienta jest przekazywane do tego modułu który przeprowadza specyficzne dla niego operacje rezultat jest przekazywany z powrotem aplikacji 7

8 Cele które przyświecały twórcom PAM administrator systemu powinien mieć możliwość wyboru domyślnego mechanizmu uwierzytelniania dla danej maszyny (od prostych haseł poprzez biometrię do kart elektronicznych) mechanizmy uwierzytelniania powinny mieć możliwość konfiguracji z uwzględnieniem potrzeb poszczególnych aplikacji (np. hasła jednorazowe dla dostępu zdalnego, tradycyjne hasła dla lokalnego logowania) możliwość stosowania jednocześnie wielu protokołów uwierzytelniania, konfigurowane zależnie od aplikacji umożliwienie uwierzytelniania wszystkimi sposobami bez potrzeby ponownego podawania hasła (wygoda użytkownika) interfejs programisty nie ulega zmianie, gdy zamieniane są wewnętrzne mechanizmy sprawdzania tożsamości (nie trzeba posiadać źródeł programów aby zmienić schemat uwierzytelniania) 8

9 Konfiguracja Pliki konfiguracyjne łączą aplikacje (usługi) i moduły PAM które dokonują uwierzytelniania. Położenie plików konfiguracyjnych Solaris: Linux: /etc/pam.conf /etc/pam.d/<app_name> Położenie modułów: Solaris: /usr/lib/security Linux: /lib/security Właścicielem modułu musi być root Inaczej moduł nie zadziała 9

10 Format pliku konfiguracyjnego Linux: auth required /usr/lib/security/pam_unix.so.1 debug (module type) (control flag) (module path) (options) Solaris: login auth required pam_unix.so.1 debug (service name) (module type) (control flag) (module path) (options) Moduł może znajdować się w dowolnym katalogu, podajemy wtedy ścieżkę bezwzględną. Ścieżki względne moduł będzie poszukiwany w katalogu domyślnym 10

11 Funkcje Zarządzanie: uwierzytelnianiem: potwierdzenie tożsamości podmiotu kontem (account management): sprawdzenie, czy użytkownik powinien otrzymać dostęp do konta, może implementować wygasanie konta, ograniczenia godzin w których możliwy jest dostęp do konta sesją (session management): funkcje do zarządzania sesją i rozliczeń, np. ustanawianie limitów na zasoby, ustalanie czasu trwania sesji hasłem (password management): zmiana, sprawdzanie poprawności (czy podobne do poprzedniego itp. cracklib) 11

12 Grupowanie modułów (stacking) Pozwala zrealizować uwierzytelnianie za pomocą wielu mechanizmów (modułów). Linux: /etc/pam.d/su auth sufficient pam_wheel.so trust auth required pam_wheel.so deny group=nosu auth sufficient pam_rootok.so Poprzez umieszczenie odpowiednich wpisów można sprawić, ze będzie wywołanych wiele mechanizmów uwierzytelniających w odpowiedniej kolejności. Jeżeli któryś z procesów uwierzytelniania się nie powiedzie, control_flag decyduje który błąd zwrócić do użytkownika. 12

13 Grupowanie modułów znaczenie flag kontrolnych required: ustawiane gdy poprawne uwierzytelnienie dla tego modułu jest konieczne. kod błędu jest zwracany aplikacji po wykonaniu wszystkich innych modułów z danego stosu. Aby funkcja się powiodła, wszystkie moduły w stosie, oznaczone jako required muszą zakończyć swoje zadania sukcesem. requisite: poprawne uwierzytelnienie dla tak oznaczonego modułu jest konieczne. W przypadku porażki kod błędu jest przekazywany aplikacji od razu, kolejne moduły nie są wykonywane. optional: użytkownik może uzyskać dostęp, nawet jak tak oznaczony moduł zakończy się niepowodzeniem. sufficient: używany w przypadku, gdy powodzenie tego modułu wystarczało do zakończenia uwierzytelniania sukcesem. Wszystkie moduły po tak oznaczonym module, w przypadku sukcesu, s± pomijane (nawet required i requisite). W przypadku niepowodzenia moduły sufficient traktowane s± jak optional. 13

14 /Solaris/ Grupowanie modułów przykład Service Module_type Control_flag Module_path Options login auth required pam_kerb_auth.so debug login auth required pam_unix_auth.so use_mapped_pass login auth optional pam_rsa_auth.so try_first_pass uwierzytelnianie kerberos oraz unix musi się zakończyć się powodzeniem uwierzytelnianie opcjonalne RSA może się nie powieść 14

15 Mapowanie haseł Wiele mechanizmów uwierzytelniania dostępnych na danej maszynie. Użytkownik musi pamiętać wiele haseł? Standard przewiduje wykorzystanie mapowania haseł pozwala posiadać różne hasła dla każdego z mechanizmów master password używane do ochrony pozostałych haseł (secondary passwords) 15

16 Parametry mapowania haseł Podajemy jako parametr modułu. Parametry: use_first_pass użyj tego samego hasła jakie zostało uzyskane w pierwszym module; nie pytaj o hasło ponownie jeżeli nie możesz uwierzytelnić za jego pomocą try_first_pass jak wyżej, z tym, że w przypadku niepowodzenia zapytaj o hasło ponownie use_mapped_pass użyj mapowania haseł aby uzyskać bieżące hasło dla tego modułu; nie pytaj o hasło użytkownika gdy uwierzytelnianie się nie powiedzie try_mapped_pass - jak poprzednie, z wyjątkiem, że zostanie wysłane zapytanie o hasło w przypadku niepowodzenia hasła uzyskanego za pomocą mapowania 16

17 Domyślna polityka Konfiguracja other W przypadku, gdy nie ma pliku konfiguracyjnego dla danego serwisu wykonywane są domyślnie akcje z serwisu oznaczonego jako other. domyślna zawartość pliku /etc/pam.d/other (Linux) auth required pam_unix.so account required pam_unix.so password required pam_unix.so session required pam_unix.so zalecana auth required pam_deny.so auth required pam_warn.so account required pam_deny.so account required pam_warn.so password required pam_deny.so password required pam_warn.so session required pam_deny.so session required pam_warn.so 17

18 Podsumowanie: Zalety: Elastyczność Łatwo wprowadzać zmiany, dodawać nowe mechanizmy uwierzytelniające, poprawiać usterki (nie trzeba zmieniać wszystkich programów, tylko wadliwy moduł) Standard RFC-86.0 przenośność 18

19 Podsumowanie: Wady: Błąd w jednym module rzutuje na wszystkie aplikacje z niego korzystające, zaufanie do dostawców modułów Trudność w administracji, błędy konfiguracji przenosz ą si ę od razu na wszystkie aplikacje korzystające z danej usługi uwierzytelniającej 19

20 Literatura [1] Solaris PAM Documentation, wwws.sun.com/software/solaris/pam/ [2] V.Samar, C.Lai, Making Login Services Independent of Authentication Technologies, SunSoft, Inc. [3] J.Rauch, FOCUS on Sun and Linux: Pluggable Authentication Modules, Part I, may 2000 [4] Linux-PAM, [5] N.Matthew, R.Stones, Zaawansowane programowanie w systemie Linux, Helion 2000 [6] D.E.Smorgrav, Pluggable Authentication Modules, Networks Associates Technology, Inc. [7] A.G.Morgan, The Linux-PAM System Administrators' Guide, 20

21 Dziękuję za uwagę 21