Cel: umożliwienie elastycznej kontroli dostępu do systemu i programów przez wprowadzenie możliwości definiowania własnych modułów dostępu.
Rozwiązanie: ładowalne moduły autoryzacji (Pluggable Authorization Modules, PAM), popularnie zwane wtyczkami, zawierające specjalizowane procedury związane z bezpieczeństwem, np. procedury identyfikacji oparte o RIPEMD-160, SHA3 czy linie papilarne, ale też nakładanie dodatkowych ograniczeń (np. na liczbę jednoczesnych loginów).
Dla danej aplikacji administrator ustala (plikiem konfiguracyjnym), które z nich i jak mają być użyte.
Wprowadzenie procedur obsługiwanych za pomocą PAM wymaga działań na 3 poziomach:
1. Programista aplikacji:
umieszcza w programie (np. /bin/login) odpowiednie wywołania funkcji dla ładowalnych modułów autoryzacji (no i linkuje program z odpowiednią biblioteką).
2. Programista modułów:
pisze ładowalne moduły autoryzacji zawierające specjalizowane metody identyfikacji (np. RIPEMD-160, SHA3, linie papilarne), które będą używane w aplikacjach.
3. Administrator:
instaluje i modyfikuje pliki konfiguracyjne dla aplikacji i modułów autoryzacji (i zapewne także instaluje moduły w systemie).
Na co dzień najbardziej istotny jest poziom 3.
Struktura systemu PAM dzieli się na 4 w miarę niezależne grupy zarządzania (zwane też typami):
- auth: zarządzanie identyfikacją (jak rozpoznajemy, o którego użytkownika chodzi), uwierzytelnieniem czyli autentyfikacją (jak rozpoznajemy, że dany faktyczny podmiot odpowiada podmiotowi zarejestrowanemu w systemie) oraz podstawowymi formami autoryzacji (jakie podmiot ma prawa do działania w systemie),
- account: zarządzanie kontami i bardziej zaawansowaną autoryzacją: określanie, czy użytkownik ma prawo dostępu do danej usługi, czy może zalogować się o danej porze dnia itp.
- session: zarządzanie sesjami (np. limity),
- password: zarządzanie aktualizacją żetonów identyfikujących (np. haseł).
Niektóre programy, np. login, potrzebują usług z wszystkich czterech grup. Inne, takie jak passwd, mogą korzystać tylko z wybranych grup.
Każda aplikacja chcąca używać PAM ma plik konfiguracyjny zawierający listę modułów dla procesu uwierzytelniania. Nazwa pliku nie musi być zgodna z nazwą aplikacji, często na początek używa się „cudzych”, sprawdzonych plików.
Pliki te znajdują się w katalogu /etc/pam.d (w starych wersjach mógł być jeden wspólny plik /etc/pam.conf, obecnie jest on używany tylko gdy brak katalogu /etc/pam.d), na przykład dla /bin/login plikiem tym będzie /etc/pam.d/login.
Plik konfiguracyjny o nazwie other zawiera wartości domyślne (zwykle zabrania wszystkiego). Są w nim tylko odwołania do modułu pam_deny, ewentualnie poprzedzone przez odwołaniami do pam_warn. Tego pliku używa się (również jako początkowego szablonu) dla services bez własnych plików konfiguracyjnych (oczywiście, gdy używają PAM).
Moduł pam_deny po prostu odmawia dostępu (zawsze zwraca niepowodzenie).
Moduł pam_warn rejestruje w syslogu informacje o wykonywanej operacji.
Inny popularny plik używany powszechnie to login.
Wpisy w plikach konfiguracyjnych mają postać:
<grupa> <kategoria> <moduł> [<argumenty>]
np.
auth required pam_securetty.so auth required pam_unix.so
gdzie <kategoria> to jedna z wartości:
- requisite - niepowodzenie natychmiast wraca do aplikacji z błędem,
- required - każdy taki moduł musi zwrócić sukces,
- sufficient - sukces takiego modułu i wszystkich jego poprzedników, powoduje zwrócenie sukcesu do aplikacji (niepowodzenie jest ignorowane),
- optional - „ozdobnik” bez wpływu na sukces lub niepowodzenie, ale dający możliwość rejestracji działań czy debuggowania plików konfiguracyjnych
albo „pseudokategoria”:
- include,
- substack.
Uwaga: dawniej zamiast pseudokategorii był moduł pam_stack.so --- powodował
dołączenie list z innego podanego pliku (zwykle system-auth). Można natknąć
się na takie przykłady w Internecie.
Często pojawia się pytanie, po co jest kategoria required, skoro istnieje kategoria requisite (i na odwrót)? Kategoria requisite może się przydać, np. gdy nasza polityka bezpieczeństwa każe ukrywać przed potencjalnym atakującym dalsze etapy sprawdzania autentyczności. Z kolei kategoria required może się przydać, np. gdy polityka bezpieczeństwa pozwala na przejście przez wszystkie etapy autentyfikacji, ale nakazuje, aby ukrywać przed potencjalnym atakującym, jakie kroki autentyfikacji skończyły się niepowodzeniem. Przydaje się ona również do zarejestrowania w logach systemowych wyniku działania operacji autentyfikacyjnej, który jest dostępny właśnie po jej wykonaniu.
Ostatnio w PAM wprowadzono kategorie złożone, zapisywane w nawiasach
kwadratowych. Pozwalają uzależnić wybór akcji od konkretnej wartości
zwróconej przez moduł (a nie tylko sukces/porażka). Nie będziemy ich
używać, ale mogą wystąpić w plikach, które będziecie podglądali.
Poszczególne moduły ładowane są kolejno, wiele z nich ma dodatkowe pliki konfiguracyjne zawarte w katalogu /etc/security.
Modułów PAM jest wiele, są one typu open-source, więc można je samodzielnie modyfikować. Można też pisać własne. Technicznie moduł to biblioteka ładowalna dynamicznie przez nazwę (wywołaniem dlopen()).
Trzyma się je zwyczajowo w jakimś katalogu security, np.
/lib/security
/lib64/security
/usr/lib/security
/usr/lib64/security
Zwykle nazwa modułu to pam_cośtam.so, najczęściej działa
man pam_cośtam
Przykłady:
Moduł pam_access zarządza klasycznym logowaniem do systemu lub aplikacji. W celu uaktywnienia modułu pam_access dla aplikacji login należy do jej pliku konfiguracyjnego dodać na końcu grupy account wiersz:
account required pam_access.so
Moduł pam_access ma plik konfiguracyjny /etc/security/access.conf. Każdy wiersz w nim ma postać
<uprawnienie> : <użytkownicy> : <miejsca>
Uprawnienie to jeden ze znaków + lub -. Nazwy użytkowników można oddzielać spacjami. Miejsce to nazwa komputera, LOCAL oznacza dostęp lokalny.
Inny użyteczny moduł to pam_limits. Służy on do nakładania ograniczeń ilościowych na zasoby, z jakich korzysta użytkownik, i jest uaktywniany za pomocą wpisu
session required pam_limits.so
z domyślnym plikiem konfiguracyjnym /etc/security/limits.conf. Składnia wierszy:
<dziedzina> <typ> <ograniczenie> <wartość>
gdzie <dziedzina> określa użytkowników lub grupy, <typ> to hard lub soft, zaś <ograniczenie> to np. fsize lub nproc. W celu ustanowienia ograniczenia dla użytkownika guest do tylko na jednokrotnego logowania, należy tam wpisać
guest hard maxlogins 1
Z kolei moduł pam_securetty ogranicza do konsoli możliwość logowania się na konto root.
Nie ma „kompletnej” listy modułów. W dokumentacji administratora wymienione są te, które w danym momencie przychodzą z pakietem. Ta lista się zmienia :-(żółw się rusza).
Poniżej częściowy wykaz:
pam_access: zobacz wyżej.
pam_debug: tylko do testowania.
pam_deny: zobacz wyżej.
pam_echo: wypisuje zawartośc pliku.
pam_env: ustawia zmienne środowiska.
pam_exec: wywołuje zewnętrzne polecenie.
pam_lastlog: odnotowuje czas ostatniego logowania w pliku /var/log/lastlog.
pam_ldap: autoryzacja w oparciu o LDAP server (niestandardowy).
pam_limits: nakłada ograniczenia na zasoby, plik /etc/security/limits.conf.
pam_listfile: alternatywna wersja pam_access.
pam_mail: sprawdza, czy użytkownik ma nową pocztę.
pam_motd: wypisuje "message of the day", zwykle z /etc/motd.
pam_nologin: jeśli istnieje plik /etc/nologin lub /var/run/nologin, to zwraca niepowodzenie, przy okazji wypisując zawartość tego pliku. Dla root'a zawsze OK.
pam_permit: zawsze zwraca sukces.
pam_pwhistory: sprawdza nowe hasło z ostatnio używanymi.
pam_rootok: tylko root, zwykle umieszcany w /etc/pam.d/su jako "sufficient" test, żeby root mógł stawać się zwykłym użytkownikiem bez podawania hasła.
pam_securetty: sprawdza, czy ten użytkownik ma prawo się logować z tego urządzenia. Zagląda do pliku /etc/securetty file --- jest to wyjątek, bo większość plików pomocniczych jest w /etc/security.
pam_shells: wpuszcza tylko, gdy shell użytkownika jest legalny (tz. wymieniony w pliku /etc/shells).
pam_succeed_if: pozwala sprawdzać różne warunki.
pam_tally: prowadzi licznik prób dostępu, odmawia gdy było za dużo.
pam_time: ograniczenie dostępu według reguł z pliku /etc/security/time.conf.
pam_unix: klasyczna autoryzacja UNIXowa (/etc/passwd, /etc/shadow).
pam_warn: zobacz wyżej.
pam_wheel: uprawnienia roota tylko dla członków grupy wheel.
Przykład pliku konfiguracyjnego /etc/pam.d/su dla programu su
auth sufficient pam_rootok.so # Uncomment the following line to implicitly trust users in the "wheel" group. #auth sufficient pam_wheel.so trust use_uid # Uncomment the following line to require a user to be in the "wheel" group. #auth required pam_wheel.so use_uid auth substack system-auth auth include postlogin account sufficient pam_succeed_if.so uid = 0 use_uid quiet account include system-auth password include system-auth session include system-auth session include postlogin session optional pam_xauth.so
PAM można używać również we własnych aplikacjach. Popatrzmy na przykład
#include <security/pam_appl.h>
#include <security/pam_misc.h>
#include <stdio.h>
static struct pam_conv login_conv = {
misc_conv, /* przykładowa funkcja konwersacji z libpam_misc */
NULL /* ewentualne dane aplikacji (,,domknięcie'') */
};
void main () {
pam_handle_t* pamh = NULL;
int retval;
char *username = NULL;
retval = pam_start("login", username, &login_conv, &pamh);
if (pamh == NULL || retval != PAM_SUCCESS) {
fprintf(stderr, "Error when starting: %d\n", retval);
exit(1);
}
retval = pam_authenticate(pamh, 0); /* próba autoryzacji */
if (retval != PAM_SUCCESS) {
fprintf(stderr, "Chyba się nie udało!\n");
exit(2);
}
else
fprintf(stderr, "Świetnie Ci poszło.\n");
printf("OK\n"); /* rzekomy kod aplikacji */
pam_end(pamh, PAM_SUCCESS);
exit(0);
}Po wywołaniu pam_start zmienna pamh będzie zawierać dowiązanie do obiektu PAM, który będzie argumentem wszystkich kolejnych wywołań funkcji PAM.
Zmienna pam_conv to struktura zawierająca informacje o funkcji do konwersacji z użytkownikiem -- tu użyliśmy najprostszej bibliotecznej funkcji misc_conv, można jednak użyć własnej.
Pierwszy argument funkcji pam_start to nazwa aplikacji, potrzebna do odnalezienia pliku konfiguracyjnego. Żeby nie trzeba było go pisać i instalować (wymaga uprawnień roota) można użyć nazwy innej już skonfigurowanej aplikacji (tutaj login) -- będziemy mieć takie same reguły. Lepiej jednak mieć własną nazwę (np. "moje"), wtedy w katalogu /etc/pam.d powinien istnieć plik o tej nazwie (np. kopia pliku "login"). Pozwoli to używać nazwy tej aplikacji w plikach konfiguracyjnych w /etc/security.
Funkcja pam_authenticate uruchamia ,,motor'' sprawdzania PAM -- usługę auth. Dla pozostałych usług/grup istnieją analogiczne funkcje, szczegóły w podręczniku. Funkcja pam_end po prostu kończy sesję (czytając podręcznik man do tej funkcji, zwróć uwagę na gospodarkę zasobami).
Przy kompilacji i linkowaniu należy pamiętać o bibliotekach libpam i libpam_misc, np.
gcc -o tescik tescik.c -lpam -lpam_misc
Podstawowa biblioteka libpam zawsze jest zainstalowana (w /lib lub /usr/lib), nawet nie warto sprawdzać. Trzeba zapewne doładować ,,development''. Na fedoropodobnych systemach to pakiet pam-devel, w Debianie (czyli w laboratorium) to libpam0g-dev. Można też załadować libpam-doc jeśli nie ma. W naszej pracowni
apt-get install libpam0g-dev
Trzy podstawowe procedury autentykacji w PAM to:
1. pam_start(): funkcja PAM która powinna być wywołana na początku. Inicjalizuje bibliotekę PAM, czyta plik konfiguracyjny i ładuje potrzebne moduły autentykacji w kolejności podanej w pliku konfiguracyjnym. Zwraca referencję do biblioteki PAM, której należy używać w następnych wywołaniach.
2. pam_end(): ostatnia funkcja PAM, którą powinna wołać aplikacja. Po jej zakończeniu jesteśmy odłączeni od PAM, a pamięć PAM zostaje zwolniona.
3. pam_authenticate(): interfejs do mechanizmu autoryzacji załadowanych modułów. Wołana przez aplikację najczęściej na początku, żeby zidentyfikować użytkownika.
Inne pożyteczne procedury PAM to:
- pam_acct_mgmt(): sprawdza czy konto bieżącego użytkownika jest aktywne.
- pam_open_session(): rozpoczyna sesję.
- pam_close_session(): zamyka bieżącą sesję.
- pam_setcred(): zarządza tokenami uwierzytelniającymi.
- pam_chauthtok(): zmienia żeton identyfikacji (zapewne hasło).
- pam_set_item(): modyfikuje wpis w strukturze stanu PAM.
- pam_get_item(): pobiera podany element stanu PAM.
- pam_strerror(): zwraca komunikat dla błędu.
Nagłówki tych procedur są w security/pam_appl.h. Warto obejrzeć podręczniki man tych funkcji.
Funkcja konwersacji obsługuje współpracę modułu z aplikacją, dostarczając modułowi metody odpytywania użytkownika o nazwę, hasło itp. Jej sygnatura to:
int conv_func (int, const struct pam_message**,
struct pam_response**, void*);Zwykle używa się bibliotecznej funkcji misc_conv.
Materiały:
Główne strona projektu to http://www.linux-pam.org/. Zawiera dokumentację i link do repozytorium kodu, m.in. A.G. Morgan, T. Kukuk ,,The Linux-PAM System Administrators' Guide''
Andrew G. Morgan ,,Pluggable Authentication Modules for Linux'' Linux Journal #44 (12/1997), http://www.linuxjournal.com/article/2120. Artykuł twórcy implementacji dla Linuksa, zawiera m.in. przykład programu używającego PAM.
Stara strona dystrybucyjna wszystkich materiałów dla Linuksa (http://www.kernel.org/pub/linux/libs/pam/) ma obecnie znaczenie historyczne. Ogólnie na sieci jest nieco materiałów przestarzałych, np. z roku 2001. Zostaliście ostrzeżeni!
A poza tym u nas na stronie SO:
tekst Pani Barbary Domagały
W małym banku spółdzielczym z poprzednich zajęć chcesz ulepszyć organizację pracy dwóch pracowników, którzy zarządzają lokatami i kredytami. Napisz wstępną wersję programu, który w przyszłości pozwoli pracownikom na logowanie się do systemu za pomocą prowizorycznej autentykacji dwuskładnikowej. Pracownik może się zalogować pod warunkiem, że poda hasło, a następnie losową liczbę, jaka wyświetli się mu w innym kanale komunikacyjnym. W naszym przypadku niech to będzie wybrana konsola tekstowa (np. tty3). Odpowiedni zestaw plików z kodem i makefile do zbudowania programu zapakowane w archiwum prześlij na Moodle.