Linux PAM – centralne zarządzanie mechanizmami logowania serwera

Wstęp

 W początkach Linuksa dużym problemem był fakt, że każdy podsystem (np. serwer pocztowy, serwer ftp) albo korzystały z centralnej bazy autorazycyjnej (mam na mysli pliki /etc/passwd i /etc/shadow) albo miało własne mechanizmy autoryzacji (np. z specjalnego pliku, bazy danych czy obecnie serwera LDAP). Prowadziło to (i prowadzi dalej) do rozproszenia mechanizmów autorazycji po wielu miejscach systemu, w przypadku chęci zmiany sposobu autorzyacji trzeba albo zmieniać program z którego korzystamy albo napisać do niego własny mechanizm autorazyacji (spróbujcie np. zrobić tak aby użytkownicy użytkownicy ftp nie mieli fizycznych kont na serwerze, czyli byli wirtualnymi użytkownikami, a pewna ich grupa mogła logować się jedynie w okreslonych godzinach w okreslonych dniach).

Problemy z tym wiązane postanowiono rozwiązać tworząc centralny dla serwera mechanizm autoryzacji, do którego usługi zgłaszałyby się z pytaniem czy dany użytkownik ma prawo skorzystać z danego zasoby czy nie, w którym następuje zmiana parametrów logowania (czyli np. zmiana hasła przypisana do loginu) itp. Mam tu na mysli Linux-PAM czyli (Pluggable Authentication Modules for Linux).

 

Zarys zasady działania Linux-PAM

Linux-PAM jest:

  • przezroczystym dla aplikacji zewnętrznej. Oznacza to, iż aplikacja zewnętrzna przekazuje mechanizmowi PAM np. zadanie autorzyacji użytkownika, bez wnikania jak on to zrobi. Korzysta po prostu z dobrze znanego API. Zadaje na przykład pytanie o to czy dany użytkownik może się zalogować przekazując login, hasło i adres z którego on się łączy i oczekuje na odpowiedzieć „tak, moze się łączyć” albo „niech idzie w jasną cholere, my tu go nie chcemy”.
  • mechanizem modularnym. Oznacza to że bez zmiany działania apliacji i potrzeby rekompliacji Linux-PAM możemy na przykład zmienić mechanizm logowania logowania z prostego sysstemu login + hasło na np. oparty o sprzętowe tokeny (specjalne urządzenie generujące według odpowiedniego algortymu liczby)  + login do systemu.
  • pozwalającym mieszać metody autoryzacji. Jestescie wstanie stworzyć dla okreslonej uslugi (i tylko wylacznie dla niej) sposób autoryzacji wymagający spełnienia kilku warunków, np. użtykownicy muszą istnieć w centalnym katalogu  pracowników opartym na serwerze LDAP firmy oraz jednoczesnie w specjalnej bazie danych SQL która np. pozwala wystawiać klientowi rachunek za korzystanie z usługi. Jeżeli te dwa warunki nie są spełnione, użytkownik nie ma prawa skorzystać z usługi.
  • tworzyć wlasne mechanizmy autoryzacji, np. co losowo wybrany użytkownik może za darmo skorzystać z super szybkiego serwera ftp (a inni muszą zapłacic sms-em) albo kto kopnie w drzwi serwerowni w okreslone miejsce (gdzie jest podłączony czujnik z komputerem) może wejsc do niej bez autoryzacji.

Każdy moduł PAM zwraca kod kontrolny okreslający czy test przeprowadzany w module dał efekt pozytywny czy negatywny (np. czy login i hasło jest poprawne).

Instalacja

Pakiet PAM jest dostępny w ramach prawie każdej dystrybucji. O ile wiem slackware bardzo długo się bronił przed emchanizmem PAM ale chyba w ostatecznosci został tam wprowadzony jako opcja.

 

Konfiguracja

Standardowa konfiguracja pakietu odbywa się przez edycję globalnego pliku konfiguracyjnego /etc/pam.conf albo przez edycje plików dotyczących poszczególnych usług znajdujących się w katalogu /etc/pam.d. Jeżeli katalog ten istnieje, plik /etv/pam.conf jest ignorowany. W chwili obecnej praktycznie nie używa się głównego pliku konfiguracyjnego, dlatego skupimy się na drugim typie konfiguracji. Zanik korzystania z jednego głównego pliku konfiguracyjnego wynika chyba z jego niewygody. ?atwiej jest stworzyć pakiet oprogramowania (mam na mysli pakiety RPM, DEB itp) zawierający specjalny plik zasad konfiguracji PAM dla danego programu, niż pisać ogólny plik zasad przewidujący wszystkie przypadki lub psecjalne narzędzie, które bedzię go tworzyło i edytowało. Zasada pojania pliku /etc/pam.conf gdy jest katalog /etc/pam.d wynika oczywiscie z faktu potrzeby posiadania jednego miesjca skąd pobierana jest konfiguracja.

Ogólna składnia pliku

typ_dzialania kontrola_zachowania nazwa_modulu parametry_dla_modulu

Typ działania

Twórcy PAM okreslili 4 zasadnicze grupy działań, którymi powinien zajmować się mechanizm PAM:

Autentyfikacji – czyli czy dany użytkownik, jest tym, za kogo się podaje. Typowy sposób to podanie loginu i hasła. Jeżeli je znasz jestes tym za kogo się podajesz. Sprawy związane z tym zagadnieniem okresla sekcjia auth.

sprawdzenie konta – czyli czy konto użytkownika nie jest zablokowane, czy nie powinien zmienić hasła, czy należy do grupy użytkowników, który mają prawo korzystać z danej usługi itp. Słowo kluczowe to account.

zarządzania hasłem – wywoływane przy zmianie hasła, moduły tej grupy pozwalają sprawdzić czy nowe hasło nie jest za proste, czy wczesniej nie zostało użyte, czy nowe hasło spełnia okreslone zasady itp. Słowo kluczowe to password.

zarządzania sesją – moduły tej grupy pozwają ustawić na szytwno zmienne systemowe dla danego użytkownika, utworzyć mu katalog domowy jeżeli go nie ma w momencie logowania, ustawić ograniczenia systemowe (np na wykorzystanie procesora, pamięci) czy mountowanie katalogu domowego. Zadania z tej grupy wykonywane są również podczas wylogowania z systemu. Słówko kluczowe to session.

Kontrola zachowania

Kolejna sprawa, którą twórcy musieli rozwiązać jest okreslenie j,ak powinien zachować się mechanizm PAM gdy test robiony przez moduł przebiegnie negatywne lub pozytywnie. Postanowili że możliwe są następujące zachowania:

requisite – gdy pojawi się błąd,  mechanizm PAM natychmiast kończy działanie.

required – mechazim PAM zgłosi błąd ale analiza stosu reguł będzie przebiegać dalej (przydatne gdy testy dostępu są wielostopniowe, czyli wiele modułów z własnie tą zasadą nie zgłosi błędu), 

sufficient – sukces tego modułu jest wystarczający do zakończenia działania mechanizmu PAM, chyba że wczesniej którys z modułów z regułą required zgłosił błąd (rezulatat OK – sukces);

optional – jeżeli jest to jedyny moduł w danej sekcji, rezultat jego testu jest ważny dla mechanizmu PAM, w innym przypadku jest ignorowany.

Nazwa modułu

 Następnie oczywiscie okreslamy o jaki moduł nam chodzi wskazując jego nazwę lub dokładną scieżkę.

Parametry modułów

Każdy moduł może przyjmować parametry, np. moduł cracklib.so przyjmuje parametry okreslające jak mocne ma być hasło.

Przykłady konfiguracji

Mozliwosć logowania się root-a bez podawania hasła

Pierwsza linia pliku /etc/pam.d/system-auth (dla fedory 6) powinna wyglądać następująco:

auth requisite pam_rootok.so

Możliwosć logowania się użytkownika o UID 500 bez podawania poprawnego hasła

Czyli praktycznie bez podawania hasła. Cała sekcja w pliku /etc/pam.d/system-auth (dla Fedory 6) powinna wyglądać następująco:

auth        requisite     pam_succeed_if.so uid = 500

Możliwosć logowania się dowolnego użytkownika bez podawania poprawnego hasła

Czyli praktycznie bez podawania hasła. Pierwsza linia w pliku /etc/pam.d/system-auth (dla Fedory 6) powinna wyglądać następująco:

auth        requisite     pam_permit.so

W Internecie

 

Dodaj komentarz