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 metody identyfikacji (np. RIPEMD-160, SHA, linie papilarne). Oprócz autoryzacji mają dodatkowe możliwości, takie jak nakładanie dodatkowych ograniczeń (np. na liczbę jednoczesnych loginów).
Dla danej aplikacji administrator ustala (plikiem konfiguracyjnym), które z nich mają być użyte.
3 poziomy:
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, SHA, 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ą, uwierzytelnieniem oraz podstawowymi formami autoryzacji,
- 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 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 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.
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.
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 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 standardowo 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 sterujący /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.
Do nakładania limitów służy moduł pam_limits:
session required pam_limits.so
z plikiem konfiguracyjnym 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. Aby pozwolić użytkownikowi guest tylko na jednokrotne logowanie, należy tam wpisać
guest hard maxlogins 1
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_cracklib: sprawdza jakość hasła ze słownikiem.
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 pam 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ę.
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 RedHatopodobnych 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 cała pamięć PAM zwolniona.
3. pam_authenticate(): interfejs do mechanizmu autoryzacji załadowanych modułów. Wołana przez aplikację najczęśćiej 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.
Funkcja konwersacji obsługuje współpracę modułu z aplikacją, dotarczając
modułowi metody odpytywania uż←tkownika 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!
Można też zajrzeć do http://wazniak.mimuw.edu.pl
A poza tym u nas na stronie SO:
tekst Pani Barbary Domagały
Cele:
- nakładanie ograniczeń na zasoby wykorzystywane przez użytkownika,
- rozszerzanie uprawnień użytkowników, aby mogli wykonywać uprzywilejowane akcje bez znajomości hasła administratora.
1. Nakładanie ograniczeń
Ograniczenia na wykorzystanie zasobów przez użytkowników ustawia administrator. Najlepiej, jeśli robimy to używając PAM (daje on możliwość ustawienia większego repertuaru ograniczeń).
Ustawianiem ograniczeń zajmuje się moduł pam_limits.so --- zwykle jest on wstępnie skonfigurowany i wystarczy do pliku /etc/security/limits.conf wpisać odpowiednie ograniczenia. Wiersze w tym pliku mają postać
<zakres> <typ> <zasób> <wartość>
Zakres podaje, kogo dotyczy ograniczenie, może to być:
- nazwa użytkownika,
- nazwa grupy poprzedzona znakiem @,
- skrót notacyjny * oznaczający wszystkich (poza rootem).
Typ określa, czy ograniczenie jest łagodne (soft), czy surowe (hard). Użytkownicy mogą poleceniem ulimit podwyższać ograniczenia łagodne.
Zasób podaje nazwę ograniczenia, np. fsize to rozmiar pliku, nofiles to liczba otwartych plików, maxlogins to liczba jednoczesnych zalogowań, a nproc to liczba procesów.
Przykład: aby ograniczyć liczbę procesów użytkownika guest, w pliku konfiguracyjnym umieszczamy
guest soft nproc 40 guest hard nproc 80
Do oglądania i modyfikowania ograniczeń przez użytkowników służy polecenie wewnętrzne shella ulimit, dlatego nie należy czytać
man ulimit
(bo on bywa czasem dziwaczny), lecz poszukać w tym, co daje
man bash
(albo nasz inny ulubiony shell). Na pewno warto użyć
ulimit -a
żeby zobaczyć wszystkie swoje ograniczenia i opcje przestawiające je.
2. Chwilowe rozszerzanie uprawnień użytkowników
Pewne operacje wymagają uprawnień posiadanych tylko przez niektórych użytkowników (np. tylko przez administratora). Jeśli chcemy pozwolić innym na ich wykonywanie (np. sterowanie podsystemem drukowania), to mamy dwie możliwości:
a) Rozdać im hasło roota, aby mogli się nań zalogować (na innego użytkownika można się chwilowo zalogować pisząc
su root
lub
su - root
Ta możliwość wydaje się jednak (przynajmniej większości administratorów) mało atrakcyjna. Można użyć modułu pam_wheel w pliku su i ograniczyć użycie polecenia su tylko do grupy wheel.
b) Na szczęście istnieje polecenie sudo. Nie wymaga ono znajomości hasła roota, lecz jedynie własnego, użytkownik musi jednak być sudoersem.
Informacje o sudoersach znajdują się w pliku konfiguracyjnym /etc/sudoers. Nie powinno się go edytować bezpośrednio, lecz użyć polecenia visudo.
Na początku pliku można umieścić aliasy, zawsze jest dostępny alias ALL. Wiersze w zasadniczej części pliku mają postać
<użytkownik> <komputer>=(<efektywny-użytkownik>) <programy>
na przykład
dobo ALL=(ALL) ALL
powoduje, że użytkownik dobo ma na wszystkich objętych tym plikiem komputerach wszelkie prawa (ale nie zna hasła roota). Aby ograniczyć to do lokalnego komputera i uprawnień root można napisać
dobo localhost= ALL
Można ograniczyć działanie sudo tylko do niektórych poleceń, sudoer może poznać swoje możliwości przez
sudo -l
3. Mechanizm SUID i SGID
Niektóre aplikacje (np. passwd) wymagają uprzywilejowanego dostępu do chronionych zasobów, takich jak pliki. Oczywiście nie ma sensu czynić wszystkich sudoersami. Dlatego plik wykonywalny (czyli program) może mieć ustawiony specjalny bit powodujący, że wykonuje się on z prawami
swojego właściciela lub grupy, a nie tego, kto go uruchomił.
Pliki takie nazywa się SUID (od Set UID) bądź SGID (Set GID). Generalnie mechanizm ten jest niebezpieczny, bo nie jest dostępna zbiorcza informacja o takich programach w naszym systemie (ale polecenie find ,,poleca się łaskawym klientom'').
Ustawianie takiego bitu w programach mających możliwość wykonania dowolnego innego programu (shelle, programy w C wywołujące system(...)) świadczy o dużej wrodzonej życzliwości właściciela programu --- należy go trzymać z dala od administrowania systemem.
Materiały:
man sudo man sudoers
http://wazniak.mimuw.edu.pl/index.php?title=Bezpiecze%C5%84stwo_system%C...
1. Załóż użytkownika burak.
2. Zabroń mu logowania się kiedyś tam.
3. Pozwól użytkownikowi guest na zdalne logowanie się tylko z sąsiedniego komputera.
4. Ustaw temu użytkownikowi maksymalny rozmiar pliku na <n> kilobajtów.
1. Używając PAM, ogranicz użytkownikowi luzer możliwość logowania (zdalnego i lokalnego) do godzin 14:30-14:45 (lub inny dogodny do sprawdzania termin).
2. Zabroń mu wielokrotnego logowania do systemu oraz ogranicz mu wielkość tworzonych plików do <n>KB (w pracowni 5 listopada <n> to około 280, zależy od tego, co robią skrypty startowe).
3. Ogranicz użytkownikowi luzer maksymalny czas wykorzystania procesora do 2 minut.
4. Użyj SUDO, aby użytkownik guest mógł dokonywać zamknięcia systemu
/sbin/shutdown now
(albo używać innej ulubionej ,,cudzej'' aplikacji).
1. Używając PAM, ogranicz użytkownikowi luzer możliwość logowania zdalnego do godzin 14:30-14:45 (lub inny dogodny do sprawdzania termin).
2. Zabroń mu wielokrotnego logowania do systemu oraz ogranicz mu wielkość tworzonych plików do <n>KB (w pracowni <n> to około 280, zależy od tego, co robią skrypty startowe).
3. Ogranicz użytkownikowi guest maksymalny czas wykorzystania procesora do 1 minuty.
4. Użyj SUDO, aby użytkownik luzer mógł dokonywać zamknięcia systemu
/sbin/shutdown now
(albo używać innej ulubionej ,,cudzej'' aplikacji).
1. Utwórz użytkowników user1, user2 i user3.
2. Skonfiguruj sudo tak, aby wszystkie próby użycia były logowane w /var/log/sudo.
3. Skonfiguruj sudo, aby użytkownik user1 mógł instalowac pakiety przez apt-get.
4. Skonfiguruj PAM tak, żeby tylko użytkownicy user2 i user3 mogli logować się
zdalnie przez SSH.
1. Utwórz użytkowników user1, user2 i user3.
2. Zezwól użytkownikowi user1 tylko na dwukrotne logowanie do systemu
oraz ogranicz jego maksymalną liczbę procesów na 20.
3. Skonfiguruj sudo, aby użytkownik user2 mógł ,,podglądać'' ruch
sieciowy (programem tcpdump).
4. Zabroń (używając PAM) użytkownikowi user3 (a może też root) zdalnego
logowania się przez SSH.
1. Wzorując się na przykładowym programie, napisz program sprawdzający,
czy podany przez użytkownika wiersz tekstu jest palindromem.
Program powinien wczytywać kolejne wiersze i dla każdego wypisywać
na terminalu ,,Tak'' lub ,,Nie''.
Po napotkaniu wiersza zawierającego kropkę program powinien kończyć
pracę.
Program powinien używać PAM: dostęp do programu powinien być
dozwolony tylko dla autoryzowanych hasłem użytkowników. O nazwę
(login) użytkownika program powinien pytać ,,Kto to?''
Ponadto program powinien umożliwiać nakładanie ograniczeń na dni i
godziny, kiedy można z niego korzystać.
2. Używanie programu powinno być dozwolone między 11:00 i 11:30
(lub w innym pasującym do labu terminie - konkretne wartości
nie mogą być zaszyte w aplikacji).
3. Skonfiguruj sudo, aby użytkownik user2 (należy go założyć) mógł
ręcznie wyłączać system (polecenie shutdown).
4. Zezwól użytkownikowi user2 tylko na dwukrotne logowanie do systemu.
Po napotkaniu wiersza zawierającego kropkę program powinien kończyć
pracę.
Program powinien używać PAM: dostęp do programu powinien być
dozwolony tylko dla autoryzowanych hasłem użytkowników. O nazwę
(login) użytkownika program powinien pytać ,,Kto to?''.
Ponadto program powinien umożliwiać nakładanie ograniczeń na dni
i godziny, kiedy można z niego korzystać.
Uwaga: wierszy tekstu może być dużo i mogą mieć różną długość.
Program konsumujący za dużo pamięci (tzn. nie zwracający nieużytków)
zostanie potraktowany limitami na rozmiar pamięci.
Pliki źródłowe programu (wraz z Makefile) należy wysłać prowadzącym
w postaci spakowanego archiwum do godziny 19:00 dnia poprzedzającego
zajęcia.
Wzorując się na przykładowym programie, napisz w języku C program znajdujący w podanym na wejściu tekście pięć najczęściej użytych słów (czyli takich, które wystąpiły najwięcej razy). Przez słowo w tym przypadku rozumiemy dowolny ciąg liter, otoczony innymi znakami.
Tekst zakończony jest wierszem zawierającym jedynie symbol "==". Po napotkaniu końca tekstu należy wypisać pierwszy wiersz tekstu i pięć znalezionych słów.
Na wejściu może wystąpić więcej niż jeden tekst, wtedy należy tę operację wykonać dla każdego tekstu osobno. Po napotkaniu wiersza zawierającego kropkę program powinien kończyć pracę.
Program powinien używać PAM: dostęp do programu powinien być dozwolony tylko dla autoryzowanych hasłem użytkowników. O nazwę (login) użytkownika program powinien pytać ,,Badania korpusowe?''.
Ponadto program powinien umożliwiać nakładanie ograniczeń na liczbę jednoczesnych uruchomień programu przez użytkownika.
Uwaga: wierszy tekstu może być dużo i mogą mieć różną długość. Program konsumujący za dużo pamięci (tzn. nie zwracający nieużytków) zostanie potraktowany limitami na rozmiar pamięci.
Zezwól użytkownikowi user2 (należy go założyć) na używanie tego programu z urządzeń znakowych tty2, tty3 lub tty4. Inni użytkownicy mogą go używać wyłącznie z terminala tty4.
Zezwól użytkownikowi user2 (należy go założyć) tylko na dwukrotne
odpalenie programu.
Używanie programu SSH powinno być dozwolone między 11:00 i 11:30 w dni powszednie (lub w innym pasującym do labu terminie - ustaw odpowiednie ograniczenie.
Skonfiguruj sudo, aby użytkownik user2 mógł instalować pakiety (polecenie apt-get).
Pliki źródłowe programu (wraz z Makefile) proszę umieścić w osobnym katalogu,który należy wysłać prowadzącym w postaci spakowanego archiwum do godziny 22:30 dnia poprzedzającego zajęcia. Nazwa katalogu i nazwa archiwum powinny zawierać login autora (np. ab123456.tgz).
Zadanie zaliczeniowe - moduły 5 i 6
------------------------------------
1. Wzorując się na przykładowym programie, napisz program sprawdzający,
czy podany przez użytkownika wiersz tekstu jest palindromem.
Program powinien wczytywać kolejne wiersze i dla każdego wypisywać
na terminalu ,,Tak'' lub ,,Nie''.
Po napotkaniu wiersza zawierającego kropkę program powinien kończyć
pracę. Uwaga: wiersze tekstu mogą być _dowolnej_ długości.
Program powinien używać PAM: dostęp do programu powinien być
dozwolony tylko dla autoryzowanych hasłem użytkowników. O nazwę
(login) użytkownika program powinien pytać ,,Kto to?''
Jednak dla root'a konieczne będzie podanie dodatkowego hasła.
Naprawdę jednak będą to dwa hasła: jedno z nich obowiązujące
od północy do godziny jedenastej (lub w innym dogodnym czasie
wypadającym w połowie zajęć), drugie w pozostałych godzinach.
Ponadto program powinien umożliwiać nakładanie ograniczeń na dni i
godziny, kiedy można z niego korzystać.
2. Używanie programu powinno być dozwolone między 11:00 i 11:30
(lub w innym pasującym do labu terminie - konkretne wartości
nie mogą być zaszyte w aplikacji).
3. Utwórz użytkowników luser1 i luser2.
4. Zezwól użytkownikowi luser1 tylko na dwukrotne logowanie do systemu
oraz ogranicz jego maksymalną liczbę procesów na 20.
5. Zezwól użytkownikowi luser2 na używanie tego programu tylko
z urządzeń znakowych tty2, tty3 lub tty4.
6. Skonfiguruj sudo, aby użytkownik luser2 mógł ,,podglądać'' ruch
sieciowy (programem tcpdump).
Pliki źródłowe programu (wraz z Makefile) proszę umieścić w osobnym katalogu,
który należy wysłać prowadzącym w postaci spakowanego archiwum tgz do godziny
22:30 dnia poprzedzającego drugie zajęcia bloku. Nazwa katalogu i nazwa archiwum
powinny zawierać login autora (np. ab123456.tgz).
Przypominamy, żę księgarnia Radagast zorganizowana jest w ten sposób, że ma dwóch menadżerów. Jeden z nich zajmuje się dostawami książek (dalej nazywany dostawcą), a drugi sprzedażą w sklepie (dalej nazywany szefem sali) i ma pod sobą pewną liczbę szeregowych sprzedawców. Zakładamy, że żaden użytkownik systemu komputerowego księgarni nie może przyjmować więcej niż jednej z powyższych ról.
Dotychczas baza danych zawierała trzy katalogi: opisy_ksiazek, zadania, raporty oraz pewną liczbę ich podkatalogów. Katalog z opisami książek pozwalał przeglądać książki w porządku alfabetycznym.
Ponieważ książki w księgarni ustawiano alfabetycznie, klienci uskarżali się, że trudno im szukać książek z interesującej ich dziedziny. Dlatego postanowiono dołożyć opisy przedmiotowe, stosując Uniwersalną Klasyfikację Dziesiętną Dewey'a (zob.
Ciocia Wikipedia albo Aunt Wiki). Dziedzinie bądź poddziedzinie wiedzy odpowiada stosowny numer. Każda książka jest zaliczana TYLKO do jednej dziedziny.
Książki będą (fizycznie) rozmieszczone w sklepie zgodnie z klasyfikacją przedmiotową, co pomoże pracownikom kierować klientów do odpowiednich regałów. Ograniczamy się do dwóch poziomów klasyfikacji.
Jak widać, ilość programów w księgarni zaczyna rosnąć. Powoduje to kłopoty z zapewnieniem bezpieczństwa aplikacji. Zdecydowano się więc na wdrożenie autoryzacji w oparciu o mechanizmy PAM. Powierzono Ci wykonanie następujących bazowych prac:
Pracę z aplikacją pracownik zaczyna od logowania się do aplikacji. Aplikacja, używając mechanizmów PAM, ustala jego poziom uprawnień.
Katalog przedmiotowy ma mieć postać drzewa hierarchii, zapisywanego pod koniec aplikacji na plik(i). Wprowadzenie nowej książki z opisem przedmiotowym powoduje automatycznie utworzenie pliku z pełnym opisem książki w katalogu alfabetycznym. W ,,drzewie'' katalogu przedmiotowego znajdą się tylko odnośniki.
Dozwolone operacje to:
Interfejs nie musi być śliczny, wystarczy tekstowa komunikacja z oknem konsoli.
W ramach oddawania zadania należy
Wszystkie materiały źródłowe należy dostarczyć w postaci spakowanego archiwum tgz, używając Moodle. Termin: dzień przed laboratorium
z odbiorem zadania.
Przecieki z działu kontroli jakości: oceniany będzie styl programowania (w zakresie bezpieczeństwa), zwłaszcza gospodarka buforami i ogólnie
pamięcią dynamiczną.
Zadanie 3: opisy merytoryczne kredytów
--------------------------------------
Przypominamy, że Green Forest Bank jest zorganizowany w ten sposób, że ma
dwa główne działy: bankowość detaliczną (DBD) i biznesową (DBB). Jeden z
nich zajmuje się obsługą klientów indywidualnych, a drugi klientów
biznesowych. Każdy dział ma swojego dyrektora, a każdy dyrektor ma pod sobą
pewną liczbę szeregowych pracowników obsługi. Zakładamy, że żaden
użytkownik systemu komputerowego banku nie może przyjmować więcej niż
jednej z powyższych roli.
Dotychczas baza danych zawierała trzy katalogi: kredyty, lokaty, zadania
oraz pewną liczbę ich podkatalogów. Katalog z opisami kredytów
pozwalał przeglądać kredyty w porządku chronologicznym.
Pracownicy uskarżali się, że trudno im szukać opisów kredytów z interesującej
ich dziedziny (np. mieszkaniowe). Dlatego postanowiono dołożyć opisy
merytoryczne stosując słowa kluczowe. Każdej dziedzinie odpowiada
pojedyncze słowo kluczowe. Każdy kredyt jest zaliczany TYLKO do jednej
dziedziny.
Do przeglądania kredytów z określonej dziedziny powstaną specyficzne
apliacje. Jak widać, ilość programów w banku zaczyna rosnąć.
Powoduje to kłopoty z zapewnieniem bezpieczństwa aplikacji.
Zdecydowano się więc na wdrożenie autoryzacji w oparciu o mechanizmy PAM.
Powierzono Ci wykonanie następujących bazowych prac:
1. Stworzenie szkieletu aplikacji w języku C dla pracowników firmy
z ustanowieniem standardu kodowania. Aplikacje mają używać
mechanizmów PAM do autoryzacji. Oprócz szkieletu programu potrzebny
będzie wzór pliku konfiguracyjnego dla PAM.
2. Wykonanie na bazie tego szkieletu próbnej aplikacji obsługującej
kredyty z określonej dziedziny (proof of concept). Ma ona mieć
dwa poziomy uprawnień:
- zwykły pracownik może przeglądać kredyty dla wybranej dziedziny,
na potrzeby tego zadania zakładamy, że przeglądanie polega na wypisaniu
pierwszych wierszy z plików tekstowych opisujących kredyty
(jakby nagłówków);
- menadżerowie mogą zmieniać klasyfikację istniejących kredytów,
wybierając kredyt i podając jego nową klasyfikację.
Pracę z aplikacją pracownik zaczyna od logowania się do aplikacji.
Aplikacja, używając mechanizmów PAM, ustala jego poziom uprawnień.
3. Ponieważ menadżerowie są leniwi i nie chce im się katalogować kredytów,
chcą mieć możliwość cedowania zwiększonych możliwości działania
na NIEKTÓRYCH pracowników. Skorzystamy do tego z mechanizmu SUDO.
Katalog opisów merytorycznych ma być osobną jednostką, zapisywaną pod
koniec pracy aplikacji na plik(i) w katalogu kredyty.
Wprowadzenie nowego kredytu powoduje automatycznie utworzenie pliku z
pełnym opisem kredytu (nasza aplikacja tego nie robi, kredyty do testowania
wprowadzimy ręcznie). Natomiast w katalogu merytorycznym przy jego
klasyfikacji znajdzie się stosowny odnośnik (umówmy się, że będzie to
ścieżka do pliku) - i to nasza aplikacja pozwala zmienić, o ile
użytkownik posiada rozszerzone uprawnienia.
Dozwolone operacje to:
- obejrzenie listy symboli klasyfikacyjnych
- obejrzenie nagłowków kredytów o podanym symbolu
- zmiana klasyfikacji dla istniejącego kredytu
- podanie listy kredytów bez klasyfikacji.
Interfejs nie musi być śliczny, wystarczy tekstowa komunikacja z oknem
konsoli.
---------------------------------------------------------------------
W ramach oddawania zadania należy
A. Przygotować szkielet aplikacji jako wzór dla innych.
B. Dostarczyć aplikację katalogu merytorycznego zgodną z powyższą:
żródła w C, pliki konfiguracyjne, skrypt/Makefile tworzący
aplikację i rozmieszczający pliki konfiguracyjne.
C. Przygotować na drugie zajęcia NIEWIELKĄ bazę testową (10 kredytów).
D. Nadać uprawnienia pracownikom (por. zajęcia 1-2),
używając SUDO należy jednemu z szeregowych pracowników pozwolić
na pełną obsługę aplikacji testowej (ale tylko na to).
Wszystkie materiały źródłowe należy dostarczyć w postaci spakowanego
archiwum tgz, używając Moodle. Termin: dzień przed laboratorium
z odbiorem zadania.
Przecieki z działu kontroli jakości: oceniany będzie styl programowania
(w zakresie bezpieczeństwa), zwłaszcza gospodarka buforami i ogólnie
pamięcią dynamiczną.