auth required pam_env.so auth required pam_unix.so try_first_pass likeauth nullok

Transkrypt

1 Moduły PAM (Pluggable Authentication Modules) Wprowadzone w celu uproszczenia konfiguracji procesu autoryzacji Można ustawić je dla wielu aplikacji o ile korzystają one z PAM. Centralizują ustawienia autoryzacji w jednym miejscu (dawnej każda aplikacja mogła mieć własny system autoryzacji co prowadziło do bałaganu). Lokalizacje plików /lib/security/ tutaj znajdują się pliki *.so z modułami. Większość ma intuicyjna nazwę okreslającą ich funkcje. /etc/pam.d/ - tutaj są pliki konfigurujące moduły PAM (notacja katalogowa) /etc/pam.conf plik konfiguracyjny modułów PAM (notacja plikowa) /etc/security/ - tutaj znajdziemy pliki konfiguracyjne dla niektórych modułów. Dzięki tym plikom można dokładniej skonfigurować dany moduł. Instalowanie modułów PAM w Debianie. Debian posiada w repozytorium dodatkowe moduły które można wykorzystać. Niektóre usługi np. LDAP, Kerberos będą wymagały ustawienia ich modułu PAM. Paczki w repozytorium zaczynają się słowem libpam. Na zajęciach instalowany był tylko moduł libpam_cracklib. Konfiguracja w notacji katalogowej. Ponieważ notacja katalogowa jest częstsza zostanie omówiona teraz. Następnie zostaną przedstawione różnice pomiędzy notacją plikową i katalogową. auth required pam_env.so auth required pam_unix.so try_first_pass likeauth nullok account required pam_unix.so password required pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3 password required pam_unix.so try_first_pass use_authtok nullok sha512 shadow session required pam_limits.so session required pam_env.so session required pam_unix.so session optional pam_permit.so Zanim omówimy wszystkie dyrektywy należy wspomnieć, że proces autoryzacji odbywa się w tzn. stosie. Oznacza to, że pewne dane uzyskane przez moduły początkowe (np. użytkownik podaje hasło) mogą być wykorzystane przez dalsze moduły bez potrzeby uzyskiwania ich ponownie. W przykładzie z hasłem oznacza to, że możemy nie pytać przy każdej usłudze użytkownika o hasło a wykorzystać to co już podał. Pierwsza kolumna zawiera dyrektywę określającą etap autoryzacji (w dokumentacji można spotkać nazwę moduł lecz wprowadzam nazwę etap aby nie mieszać). Oto znaczenie tych 4 dyrektyw: auth oznacza sprawdzenie tożsamości użytkownika np. sprawdzenie loginu i hasła account nie wykonuje żadnej czynności uwierzytelniającej ale sprawdza czy użytkownik może się zalogować do systemu. Chodzi tutaj o ograniczenia takie jak np. maksymalna liczba zalogowanych użytkowników lub obecności pliku /etc/nologin.

2 Password jest odpowiedzialny za stworzenie tokena dla użytkownika który jest właśnie logowany. Token tez zwiera informacje o użytkowniku np. UID i GID. session odpowiada za czynności i ustawienia które trzeba wykonać zanim użytkownik otrzyma dostęp do powłoki. Druga kolumna określa priorytet modułu. Można znaleźć tutaj 4 podstawowe dyrektywy: required określa, że jeżeli ten moduł zwróci błąd to cały proces autoryzacji zwróci błąd niepowodzenia. requisite określa podobnie jak required, że nie powodzenie tego modułu sprawia, że cały proces zwraca błąd ale w odróżnieniu od required jego nie powodzenie przerywa od razu dalszą autoryację. Zatem w przypadku required błąd zostanie zwrócony dopiero po zakończeniu przetwarzania wszystkich modułów. sufficient mówi, że powodzenie tego modułu wystarcza aby przerwać proces i zwrócić kod sukcesu. Natomiast jeżeli moduł required który jest przed nim zwróci błąd to sukces tego modułu jest ignorowany. optional określa, że powodzenie lub niepowodzenie tego modułu są beż znaczenia. Zostały jezcze 2 dyrektywy do omówienia: include powoduje dołączenie zawartości wskazanego pliku do stosu modułów. Substack podobnie jak include dołącza plik ale jego zawartość jest traktowana jako pod stos. Istnieje możliwość definiowania własnego priorytetu. W tym celu w drugiej kolumnie wpisujemy w nawiasu kwadratowe wartości kluczy i przypisywane im wartości według formatu: [kluczn=akcja1,kluczm=akcja2,...] Oto lista kluczy: success, open_err, symbol_err, service_err, system_err, buf_err, perm_denied, auth_err, cred_insufficient, authinfo_unavail, user_unknown, maxtries, new_authtok_reqd, acct_expired, session_err, cred_unavail, cred_expired, cred_err, no_module_data, conv_err, authtok_err, authtok_recover_err, authtok_lock_busy, authtok_disable_aging, try_again, ignore, abort, authtok_expired, module_unknown, bad_item, conv_again, incomplete, default. Akcja określa jedno z następujących słów kluczowych: ignore, bad, die, ok, done, reset Nazwy są intuicyjne ale wyjaśnienia wymaga tylko dyrektywa reset. Powoduje ona skasowane danych które zostały odłożone na aktualnym stosie PAM (np. wcześniej pobrane hasła). Jednak jeżeli jesteśmy w pod stosie to ta akcja skasuje tylko dane z tego pod stosu. Trzecia kolumna określa właściwy moduł wraz z parametrami: pam_unix.so try_first_pass likeauth nullok pam_unix.so jest nazwą modułu a reszta linijki to jego parametry. Jeżeli ilość parametrów jest zbyt długa można zastosować załamanie wiersza więc linijka: password required pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3 będzie zinterpretowana tak samo jak: password required pam_cracklib.so difok=2 minlen=8 \ dcredit=2 ocredit=2 retry=3

3 Jeżeli pominięto by znak \ wówczas w pliku z tą konfiguracją byłby błąd. Należy uważać na błędy ponieważ mogą one zablokować nam dostęp do systemu! Notacja plikowa Różnica pomiędzy notacją plikową a katalogową polega na tym, że w notacji plikowej wszystkie wpisy umieszczone są w pliku /etc/pam.conf. Dodatkowo w celu określenia do której aplikacji dotyczy wpis należy umieścić nazwę aplikacji przed nazwą etapu. Przykład: login auth requisite pam_nologin Wpis ten dotyczy aplikacji login. Tworzenie przykładowych wpisów. Wybrałem 4 moduły do omówienia, ze względu na czas spotkania ograniczałem się tylko do ciekawszych parametrów. a) pam_nologin. Moduł ten odpowiada na reakcję systemu na obecność pliku /etc/nologin który jeżeli istnieje blokuje logowanie zdalne (ssh) do systemu przez użytkowników którzy nie są administratorem (root). Zachowanie to można zmienić dodając odpowiednie wpisy w innych plikach z ustawieniami modułów PAM usług. Jego parametry to file oraz debug. Parametr file pozwala określić ścieżkę do pliku na który ma reagować ten moduł (domyślnie /etc/nologin). Obsługiwane etapy to auth oraz account. b) pam_cracklib Ten moduł służy do sprawdzania haseł ustawianych przez użytkowników systemu. Jeżeli hasła będą zbyt proste nie pozwoli on ustawić takiego hasła. Jego parametry pozwalają na wprowadzanie wymagań dla hasła. Możemy wskazać słownik który będzie uwzględniany przy testowaniu haseł. Cracklib dostarcza 5 testów które przeprowadzi na podanym haśle: test palindromów test wielkości znaków (czy nowe hasło jest tym samym ale ze zmienioną wielkością liter) test podobieństwa (głownie difok) test prostego hasła (parametry dcredits,ucredit,lcredits,ocredits oraz minlen) test rotacji hasła Oto lista ciekawszych parametrów: retry=n ustawia ile prob podania hasła ma użytkownik zanim moduł zwróci fail. difok=n określa ile znaków ze starego hasła nie może pojawić się w nowym difignore=n od ilu znaków hasła należy ignorować parametr difok minlen=n minimalna dlugosc hasla (mniej jak 6 zostanie zingorowane i zostaje przyjete 6 znakow natomiast domyslna wielkosc to 9) dcredit=n

4 jeżeli N jest większe lub równe 0 to parametr ten określa największą liczbę znaków cyfr. Znaki te są liczone do długości hasła aby spełnić wymogi parametru minlen, jeżeli podamy więcej cyfr niż N wówczas moduł nie policzy dodatkowych cyfr i nie będą one uwzględnione w minlen. Jeżeli N jest ujemne wówczas wartość bezwzględna N oznacza minimalna liczbę cyfr jaka musi zawierać hasło. ucredit=n podobnie jak dcredit ale zamiast cyfr liczymy duże litery lcredit=n podobnie jak dcredit ale zamiast cyfr liczymy małe litery ocredit=n podobnie jak dcredit ale zamiast cyfr liczymy znaki specjalne. Cracklib obsługuje tylko etap password. Przykład: password required pam_cracklib.so minlen=7 dcredits=4 ocredits=-2 retry=4 c) pam_unix Obsługuje ustawienia uwierzytelniania w lokalnym systemie. Można określić w nim algorytm szyfrowania haseł. A także ile razy hasło ma być szyfrowane. Zawiera parametry które można spotkać i w innych modułach. Chodzi tu o parametry do obsługi podanych już wcześniej haseł znajdujących się na stosie. Może pamiętać N ostatnio podanych haseł. Oto najciekawsze parametry: md5, bigcrypt, sha256, sha512, blowfish to są algorytmy szyfrowania dla haseł. rounds=n gdzie N oznacza liczbę przebiegów algorytmu, np. rounds=15 sprawi, ze 15 razy będzie szyfrowane hasło (następny przebieg szyfruje wynik poprzedniego). nodelay jeżeli podamy złe hasło to system czeka ok. 2-3 sekund zanim zwróci błąd, ten parametr wyłącza takie zachowanie. try_first_pass (dostepy np. w pam_cracklib) mówi modułowi, że należy spróbować hasło położone na stosie i w przypadku niepowodzenia należy zapytać się o hasło use_first_pass (dostępny np. w pam_cracklib) nakazuje modułowi próbować tylko hasła odłożonego na stos. Jeżeli to hasło jest błędne spowoduje to zwrócenie fail. nullok ponieważ moduł nie pozwala ustawiać pustych haseł więc uzytkownik który takie hasło ma nie mógłby go użyć np. do zmiany swojego hasła albo do dostepu. Ten parametr wyłącza to zachowanie. Obsługiwane etapy to auth,account,password oraz session. Przykład: //ta cześć znalazła by się w common-auth auth requisite pam_nologin auth requited pam_unix.so

5 //a ta w common-account account required pam_unix.so // ta natomiast w common-password password required pam_cracklib.so minlen=7 dcredits=4 \ ocredits=-2 retry=4 password required pam_unix.so use_first_pass md5 //i ostatnia w common-session session required pam_unix.so session required pam_limits.so // ten moduł pojawia się w ustawieniach niektórych // usług więc raczej nie trafiłby do tego pliku session required pam_env.so //moduł odpowiedzialny za ustawianie zmiennych // środowiskowy session optional pam_mkhomedir.so umask=033 //ten moduł tworzy katalog domowy //użytkownika jeżeli on nie istnieje, parametr //umask jest odpowiedzialny za maskę uprawnień Potrafisz powiedzieć co ta konfiguracja robi? Moduł pam_limits pojawi się już za chwilkę d) pam_limits Czasem nadchodzi potrzeba ograniczenia zasobów które dostają użytkownicy. Najbardziej znanym przykładem będzie słynna bomba forkowa. Czyli proces który tylko się mnoży i zapycha system operacyjny. Jadro nie pozwoli zając takiemu procesowi wszystkich identyfikatorów procesów (PID) zostawi ich około 5 aby użytkownik root mógł się zalogować i w miarę swobodnie podjąć akcje likwidacyjne bez potrzeby resetowania systemu. Pam_limits pozwala ograniczyć liczbę procesów którą jądro pozwoli użytkownikom utrzymywać w danej chwili. Innym przykładem może być użytkownik który utrzymuje 15 sesji i według obserwacji każda sesja jest aktywna co może świadczyć o dzieleniu konta albo o botach. W tym przypadku możemy ograniczyć liczbę równoczesnych sesji w systemie. Co na pewno utrudni takie praktyki. Jadro posiada odpowiednie struktury do ograniczania użytkowników ale to dzięki temu modułowi są one ustawiane. Opcje ograniczeń nie są podawane przy deklaracji modułu ale znajdują się w oddzielnym pliku (standardowo /etc/security/limits.conf). Ale lokalizację pliku można zmienić parametrem conf=/sciezka/do/nowej/konfiguracji Sam plik limits.conf zawiera wyjaśniony każdy parametr ale wyjaśnień może wymagać parametr cpu. Określa on maksymalny czas jaki może zużyć określony użytkownik/grupa podawany w minutach podczas swojej sesji. Po przekroczeniu tego czasu sesja się zakończy. Przykłady wpisów

6 pliku limits.conf znajdziecie w pliku limits.conf. Przyklady innych modułów pam_acces zwraca zawsze sukces pam_debug debuguje prace PAM pam_deny zwraca zawsze fail pam_echo wyświetl jakiś tekst pam_exec wykonaj jakiś program pam_lastlog włącz wyświetlanie informacji o ostatnim logowaniu pam_mail zawiadom użytkownika o poczcie pam_securetty ogranicz powłoki roota do określonych pam_selinux moduł PAM dla projektu SELinux (Security-Enhanced Linux) pam_tally/pam_tally2 zapamiętuje liczbę logowań (można go użyć do reakcji na ataki słownikowe i bruteforce) pam_warn logowanie pracy PAM pam_wheel przyznaje prawa do używania su (domyślnie nadaje je grupie wheel) Dokumentacja online modułów PAM Na stronie tej znajdują się opisy parametrów i poszczególnych modułów.