Moduły PAM (Pluggable Authentication Modules) – Wprowadzone w

Moduły PAM (Pluggable Authentication Modules) – Wprowadzone w

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
auth
required
required
pam_env.so
pam_unix.so try_first_pass likeauth nullok
account
required
pam_unix.so
password
password
required
required
pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3
pam_unix.so try_first_pass use_authtok nullok sha512 shadow
session
session
session
required
required
required
pam_limits.so
pam_env.so
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.
– 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
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
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
auth
requisite
requited
pam_nologin
pam_unix.so
//a ta w common-account
account
required
pam_unix.so
// ta natomiast w common-password
password
required
password
required
pam_cracklib.so minlen=7 dcredits=4 \
ocredits=-2 retry=4
pam_unix.so use_first_pass md5
//i ostatnia w common-session
session
session
required
required
pam_unix.so
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
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
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/Linux-PAM_SAG.html
Na stronie tej znajdują się opisy parametrów i poszczególnych modułów.