ACL i SUDO

Podstawowy model praw dostępu

Przedmiotem mechanizmów kontroli dostępu jest sprawienie, aby określone czynności mogli wykonywać wyłącznie ludzie, którym te czynności wykonywać wolno (żeby na przykład kluczowej decyzji dla funkcjonowania dużej korporacji nie podejmowała sprzątaczka). W związku z tym współczesne systemy komputerowe operują pojęciami użytkownika, zasobu oraz praw do korzystania z tego zasobu, jakie użytkownik posiada. Ten prosty model jest dodatkowo wzbogacany o mechanizmy redukujące złożoność problemu określania praw dostępu (m * n, gdzie m to liczba użytkowników, a n to liczba zasobów): prawa właściciela, prawa grupowe i prawa dla pozostałych. Indywidualne prawa może mieć tylko właściciel, można określić grupę użytkowników i dla niej nadać określone prawa do zasobu oraz można zdefiniować prawa do zasobu, jakie mają wszyscy. Chociaż ten model praw dostępu kojarzymy przede wszystkim z systemami plików (bo systemy operacyjne mają tendencję do udostępniania wszystkich swoich obiektów w systemie plików), to pojawia się on też i gdzie indziej, na przykład w bazach danych. Warto jednak pamiętać, że model ten nie pozwala na zarządzanie ilością dostępnych zasobów (czas pracy procesora, pamięć, ilość danych wysyłanych kanałem komunikacyjnym itp.). Przypomnijmy jeszcze, jakie prawa dostępu możemy określić w tym podstawowym modelu:

Prawo do odczytu (oznaczane r)
Prawo do zapisu (oznaczane w), które nie implikuje i nie zakłada istnienia prawa do odczytu. Można zapisać dane do pliku, którego nie możemy odczytać.
Prawo do wykonywania (oznaczane x), które nie implikuje prawa do odczytu, ale którego realizacja wymaga posiadania prawa do odczytu. Można wykonać plik tylko, gdy możemy go odczytać.
Prawo do korzystania z katalogu (oznaczane x), które nie implikuje i nie zakłada istnienia prawa do jego odczytu ani zapisu. Można móc czytać informacje z katalogu, ale jednocześnie nie móc się odwoływać do plików w nim się znajdujących i wchodzić do wnętrza katalogu. Podobnie można móc się odwoływać do plików w katalogu (jeśli skądinąd wiemy, że one w nim są), ale nie móc odczytać jego zawartości.

W związku z prawami do korzystania z katalogu warto nadmienić, że chociaż prawo to jest oznaczane tak samo, jak prawo do wykonywania plików, chodzi o zupełnie inny rodzaj czynności, na jakie to prawo pozwala (procesor nie wykonuje żadnych instrukcji maszynowych zapisanych bezpośrednio w treści katalogu). Stąd, chociaż wspólne oznaczenie kusi, aby te prawa utożsamiać, warto pojmować je jako prawa oddzielne i odrębne, a wspólne oznaczenie rozumieć jako wygodny skrót notacyjny. Idąc nieco dalej tym tropem, możemy zaobserwować, że prawa do korzystania z katalogu obejmują prawa do wykonywania kilku istotnie różnych czynności: czynienie katalogu katalogiem roboczym procesu, odwoływanie się do elementu katalogu, korzystanie z podkatalogów i.in. Widać zatem, że takie określenie systemu praw dostępu jest w pewnym sensie arbitralne i można byłoby sobie wyobrazić większą granulację praw sposobu dostępu do katalogu lub też jakieś odrębne prawa dla innych obiektów systemu plików (np. dla urządzeń blokowych można byłoby wprowadzić prawo do wykonywania szybkiego operacji lseek i określić je jako x). Jeszcze jednym ważnym elementem podstawowego systemu praw dostępu są prawa, jakie są nadawane nowemu elementowi systemu plików (plikowi, katalogowi etc.). Prawa te są przypisane do użytkownika, który tworzy nowe zasoby w systemie plików. Określa się je i odczytuje za pomocą polecenia umask.

Mechanizmy lokalnej kontroli dostępu

Listy kontroli dostępu (ang. Access Control List, ACL) rozszerzają standardowy mechanizm uprawnień, kontrolujący dostęp do plików (a także katalogów, urządzeń, gniazd i innych obiektów systemu plików). W porównaniu ze standardowymi mechanizmami praw dostępu ACL dają dodatkowo możliwość:

przydzielania trzech standardowych uprawnień (rwx) nie tylko dla jednego użytkownika - właściciela pliku, ale dla dowolnie wskazanych, potencjalnie wielu użytkowników,
przydzielania uprawnień nie tylko dla jednej grupy - grupy pliku, ale dla dowolnie wskazanych, potencjalnie wielu grup,
szybkiego ograniczenia praw dla wielu użytkowników,
przywiązania opisu praw, jakie otrzymują nowo tworzone zasoby, do katalogów, a nie tylko do użytkowników.

ACL są wspierane przez różne linuksowe systemy plików, mi.in.: xfs, ext2, ext3, ext4, reiserfs, nfs, jfs. Co ciekawe spośród znanych systemów plików nie obsługują ACL: FAT16, FAT32, zaś system plików exFAT w jednej z wersji systemu Windows je obsługiwał, ale współczesne wersje tego systemu list ACL w exFAT już nie obsługują. Uważa się, że ACL są zgodne ze standardem POSIX. W rzeczywistości opisujące je standardy POSIX 1003.1e i 1003.2c draft 17 nie zostały oficjalnie przyjęte. ACL są również wspierane w systemach firmy Microsoft, jednak nie zachowują one pełnej zgodności ze standardem i spośród systemów plików typowo używanych w takich systemach są wspierane jedynie przez NTFS.

Linux

1. Zawartość Listy Kontroli Dostępu

Minimalna lista kontroli dostępu pokrywa się ze standardowymi uprawnieniami, natomiast lista rozszerzona zawiera dodatkową pozycję - maskę i może zawierać także pozycje dla poszczególnych użytkowników i grup. W liście ACL wyróżniamy następujące typy pozycji (w nawiasach słowa kluczowe):

właściciel (user:: lub u::)
wskazany przez nazwę użytkownik (user:nazwa_użytkownika: lub u:nazwa_użytkownika:) [dodatkowy mechanizm]
grupa właściciela (group:: lub g::)
wskazana przez nazwę grupa (group:nazwa_grupy: lub g:nazwa_grupy:) [dodatkowy mechanizm]
maska (mask::) [dodatkowy mechanizm]
pozostali (other::)

(Uwaga: w literaturze spotyka się często określenia nazwany użytkownik czy nazwana grupa na oznaczenie wskazanego przez nazwę użytkownika i wskazanej przez nazwę grupy. Terminy te dobrze kojarzą się z angielską terminologią (named user, named group), jednak spośród wielu znaczeń angielskiego słowa name najbardziej pasujące tutaj to to mention explicitly : specify).

2. Szybkie odbieranie uprawnień - maska

Określanie odrębnych praw dla każdego użytkownika ma taką wadę, że w razie sytuacji kryzysowej (np. ataku na komputer) zmiana uprawnień wymaga żmudnej zmiany praw każdego z nich. Trudności z tym związane pozwala usunąć mechanizm maskowania praw dostępu w ACL (uwaga: chodzi o zupełnie inny mechanizm niż mechanizm związany z poleceniem umask). Dzięki temu mechanizmowi podczas obliczania efektywnych uprawnień (czyli tych, jakie użytkownik ma w momencie korzystania z zasobu w systemie plików), oprócz uprawnień zdefiniowanych dla danego użytkownika, brana jest pod uwagę także maska. Z dwoma naturalnymi wyjątkami: uprawnienia zdefiniowane dla właściciela i dla tzw. pozostałych (other) są zawsze efektywne (maska nie ma na nie wpływu). W obydwóch tych wypadkach nie mamy do czynienia z potencjalnie długą listą użytkowników, dla których musimy odrębnie określić prawa. Efektywne uprawnienia do pliku są koniunkcją bitową maski i uprawnień zdefiniowanych w odpowiedniej pozycji (dla nazwanego użytkownika, grupy właściciela lub nazwanej grupy). Przykład Jeżeli prawa do pliku zdefiniowane są w następujący sposób:

user:testowy:r-x
mask::rw-

to efektywne uprawnienia użytkownika "testowy" to: r-- Uwaga: domyślnie maska jest aktualizowana automatycznie i określa maksymalne uprawnienia dla użytkowników należących do nazwanych użytkowników, grupy właściciela lub grup nazwanych.

3. Algorytm sprawdzania uprawnień dostępu

Rozszerzone uprawnienia są stosowane wg następującego algorytmu:

jeżeli użytkownik jest właścicielem pliku - zastosuj uprawnienia właściciela,
jeżeli użytkownik jest na liście użytkowników wskazanych z nazwy - zastosuj efektywne (patrz punkt 2) uprawnienia nazwanego użytkownika,
jeżeli jedna z grup użytkownika jest grupą właściciela i posiada odpowiednie efektywne prawa - zezwól na dostęp,
jeżeli jedna z grup użytkownika występuje jako grupa wskazana z nazwy i posiada odpowiednie efektywne prawa - zezwól na dostęp,
jeżeli jedna z grup użytkownika jest grupą właściciela lub należy do grup wskazanych z nazwy, ale nie posiada dostatecznych efektywnych uprawnień - dostęp jest zabroniony,
jeżeli nie zachodzi żadne z powyższych - uprawnienia tzw. pozostałych określają możliwość dostępu.

Szczególnej uwagi wymaga tutaj przedostatni punkt.

4. Polecenia do odczytu i określania list ACL

Do zarządzania listami ACL służą dwa polecenia:

getfacl
setfacl

Polecenie getfacl wypisuje rozszerzone uprawnienia do plików. Przykład

% touch plik-testowy
% ls -l plik-testowy
-rw-r--r-- 1 janek bsk 0 2016-10-05 14:46 plik-testowy

% getfacl plik-testowy
# file: plik-testowy
# owner: janek
# group: bsk
user::rw-
group::r--
other::r--

% getfacl plik-testowy –-omit-header
user::rw-
group::r--
other::r--

Polecenie setfacl pozwala modyfikować uprawnienia.

a) Zmiana uprawnień - opcja -m

Jeżeli chcemy dodać lub zmienić uprawnienia używamy opcji -m (jak modify), a następnie podajemy: pozycję z listy (patrz punkt 1), jakie uprawnienia chcemy nadać (rwx) i jakiemu plikowi. Przykład

% setfacl -m u:ala:rwx plik-testowy

% getfacl plik-testowy
# file: plik-testowy
# owner: janek
# group: bsk
user::rw-
user:ala:rwx
group::r--
mask::rwxman setuid
other::r--

% ls -l plik-testowy
-rw-rwxr--+ 1 janek bsk 0 2016-10-05 14:46 plik-testowy

man setuid Zwróćmy uwagę na wiersz powyżej. Znak + oznacza, że plik posiada rozszerzone uprawnienia, a zamiast uprawnień grupy widzimy maskę (co nie powinno dziwić, bo maska opisuje maksymalne uprawnienia dla wszelkich grup). Maskę możemy zmieniać korzystając z setfacl (mask::), a także poprzez chmod (zmiana praw dla grupy powoduje zmianę maski).

b) Usunięcie uprawnień - opcja -x

Opcji -x (jak exclude) używa się tak:man setuid

% setfacl -x u:ala plik-testowy
% getfacl plik.txt –-omit-header
user::rw-
group::r--
mask::r--
other::r--

% ls -l plik.txt
rw-r--r--+ 1 janek bsk 0 2016-10-05 14:46 plik-testowy

man setuid Inne opcje pozwalają na przykład na usunięcie uprawnień dotyczących wszystkich pozycji (-b, jak blank), czy modyfikację uprawnień rekurencyjnie w drzewie katalogów (-R). Jest też pewna liczba opcji wiążących ACL z innymi mechanizmami systemu plików. Należy w tym momencie przeczytać systemowe strony man dla omawianych tu poleceń.

5. Prawa dostępu dostępu dla nowo tworzonych zasobów

Uprawnienia dla nowo tworzonych zasobów, zwane skrótowo uprawnieniami domyślnymi, dotyczą tylko katalogów. Jeżeli katalogowi nadamy domyślne uprawnienia ACL, to nowo utworzone pozycje w tym katalogu będą je dziedziczyć. Do modyfikowania uprawnień domyślnych służy opcja -d (jak default) polecenia setfacl, po której następują znane już -m, -x itd. Przykład dodania uprawnień domyślnych

% setfacl -d -m group:testowa:wx bsk-lab1
% getfacl bsk-lab1 –-omit-header
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::r-x
default:group:testowa:-wx
default:mask::rwx
default:other::r-x

Opcja -k kasuje domyślne uprawnienia.

Windows

Poniższe obrazki ilustrują działanie ACL w systemie Windows XP. System plików NTFS umożliwia związanie z każdym plikiem (lub katalogiem) list kontroli dostępu. Dostęp do prostych ustawień ACL pliku jest możliwy z poziomu np. Eksploratora Windows w opcji Właściwości (menu Plik lub kontekstowe). Rozszerzone listy ACL są dostępne po wyborze uprawnień Zaawansowanych.

System Windows nie zapewniał obsługi ACL dla swoich pierwotnych systemów plików FAT (FAT16 i FAT32). W Windows CE 6 wprowadzono obsługę ACL dla systemu plików exFAT, jednak w późniejszych wersjach systemu Windows nie została ona wprowadzona.

Podsumowanie

Zalety ACL:

Elastyczność, możliwość nadawania dowolnie skomplikowanych uprawnień bez konieczności tworzenia dużej liczby grup.
Ułatwienie migracji, tworzenia i konfigurowania heterogenicznych środowisk z systemami operacyjnymi Windows i Linux (oprogramowanie Samba wspiera ACL).

Problemy: nie wszystkie narzędzia wspierają ACL:

Edytory, które automatycznie zapisują zawartość w nowym pliku, a następnie zmieniają jego nazwę na oryginalną, mogą tracić informację o rozszerzonych uprawnieniach.
Programy archiwizujące (np. tar) nie potrafią zapisywać informacji o listach kontroli dostępu.

Jedną z metod radzenia sobie z drugim problemem jest zapamiętywanie informacji ACL. Na przykład polecenie:

% getfacl -R --skip-base . >backup.acl

spowoduje zapisanie do pliku "backup.acl" informacji o ACL z całego drzewa systemu plików (opcja -R) z pominięciem domyślnych uprawnień (--skip-base). Używając polecenia setfacl z opcją --restore=backup.acl, można potem przywrócić rozszerzone uprawnienia.

Czytaj też

man 5 acl man do poleceń: getfacl, setfacl, chmod, umask

Rozszerzanie uprawnień zwykłych użytkowników w Linuksie (SUDO)

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. 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

<span class="inline inline-center">
sudo -l

Mechanizm SUID i SGID

Niektóre polecenia (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
man setuid
man setgid

http://wazniak.mimuw.edu.pl/index.php?title=Bezpiecze%C5%84stwo_system%C...

Zadanie pokazujące aktywność

Wyobraź sobie, że w małym banku spółdzielczym masz zorganizować prawa dostępu do informacji o kredytach i lokatach poszczególnych klientów. Lista klientów znajduje się w pliku tekstowym, gdzie każdy wiersz ma postać:

identyfikator_klienta imię nazwisko

Chcesz udostępnić klientom dwa katalogi: lokaty i kredyty. Dodatkowo masz dwóch pracowników, którzy zarządzają lokatami i kredytami. Napisz skrypt, który stworzy odpowiednią strukturę katalogów, założy klientom oraz pracownikom konta (useradd) oraz skonfiguruje dostęp do katalogów w taki sposób aby:

każdy klient z listy miał prawo do odczytu plików, które powstaną w katalogu kredyty, a pracownik miał prawo do odczytu i zmiany plików z tego katalogu, a także miał prawo dodawać do niego elementy,
każdy klient z listy miał prawo do odczytu i zapisu plików, które powstaną w katalogu lokaty, a także miał możliwość tworzenia plików w tym katalogu; jednocześnie pracownik miał prawo do czytania plików z tego katalogu, ale nie miał prawa do ich zmieniania, dodawania i usuwania,
za pomocą polecenia sudo pracownik może przyjąć tożsamość jednego z klientów i wykonać jego operacje, dodaj do skryptu kilka operacji na lokatach i kredytach wykonywanych przez pracowników za pomocą sudo podszywających się pod klientów.

Powstały skrypt prześlij na Moodle.

Plik z listą klientów ma być parametrem skryptu.

Załącznik	Wielkość
uzytkownicy.txt	95 bajtów