Linux twardy jak skała

O plikach, dyskach i uprawnieniach …

Mając uporządkowaną kwestię usług - możemy przejść do plików. Wracając na chwilę do partycji (samo utworzenie osobnych partycji to nie koniec), warto poświęcić chwilę ich atrybutom. Te możemy modyfikować, edytując plik /etc/fstab, który odpowiada za automatyczne montowanie partycji podczas startu systemu. Jego składnia jest dość prosta. Każdy wpis powinien być skonstruowany według schematu z tabeli:

Linux twardy jak skała

Z punktu widzenia hardeningu największe znaczenie ma pole "opcje". Może ono przyjmować wiele wartości, dla nas jednak najważniejsze są nosuid, noexec, nodev.

Nosuid oznacza, że na danej partycji nie będą respektowane bity SUID i SGID. Niemniej jednak, szybka lektura pomocy do polecenia mount nasuwa wątpliwości co do skuteczności wykorzystania tej opcji, jeżeli możemy skorzystać z suidperl.

Noexec z kolei blokuje możliwość uruchomienia pliku wykonywalnego z wybranej partycji. Ale także tutaj trzeba mieć na uwadze, że mimo ustawienia tego parametru niektóre skrypty mogą w dalszym ciągu zostać wykonane, np. jeżeli wykonywane są z użyciem innego narzędzia, które ma bit SUID/SGID. Mimo to jednak dobrą praktyką jest ustawianie noexec przynajmniej na partycji /tmp. I kolejna uwaga. W pewnych szczególnych przypadkach brak możliwości uruchamiania plików wykonywalnych z /tmp uniemożliwia pracę niektórych aplikacji. Trzeba więc wykonać odpowiednie testy. Możemy też pójść nieco dalej i ustawić noexec również na partycji /home.

Nodev uniemożliwia wykorzystanie plików urządzeń na danej partycji. Z powodzeniem można tę opcję ustawić na każdej partycji z wyjątkiem /dev.

Wspominaliśmy o bitach SUID (set user ID) oraz SGID (set group ID). Obecność plików z “przypiętymi" bitami tego typu powinna być w systemie ściśle reglamentowana - zwłaszcza jeżeli są to pliki wykonywalne. To skomplikowanie wynika z faktu, że SUID/SGID oznacza, że każdy oznaczony nimi plik będzie wykonywany z uprawnieniami jego właściciela bez względu na to, kto go wykonuje. Jeżeli więc edytor "vi" miałby ustawiony SUID, a jego właścicielem był root, to zwykły użytkownik "zbychu", uruchamiając go, miałby w edycji wielu plików prawa tego pierwszego. Rozpoznanie pliku z parametrem SGID/SUID jest proste.

Weźmy na przykład narzędzie ping. Jeżeli wyświetlimy jego paramtery: ll /bin/ping otrzymamy:

Linux twardy jak skała

W tym przypadku ustawiony mamy bit SUID (oznaczony na czerwono). Z kolei /sbin/netreport ma SGID:

Linux twardy jak skała

Wiedząc powyższe, wypadałoby teraz wyszukać wszystkie pliki z SUID/SGID. Można to zrobić za pomocą polecenia find:

find / -path /proc -prune -o -type f -perm +6000 -ls

Jeżeli chcemy zdjąć SUID/SGID z pliku, wydajemy polecenie:

chmod -s [nazwa pliku]

A jeśli samo usunięcie tego bitu nie wystarczy i chcemy po prostu pozbyć się pakietu, który go sprowadził, nic prostszego. Na przykład w CentOS wystarczy najpierw odnaleźć pakiet (rpm -qf [nazwa_pliku]), a następnie go usunąć (rpm -e [nazwa_pakietu]).

Na marginesie warto też wspomnieć o pewnym nieporozumieniu związanym z SUID i SGID. Są one czasami mylone z pojęciem Sticky Bit ze względu na obecność litery "s" w atrybutach plików. Różnica jednak jest zasadnicza. Sticky bit oznaczany jest literą "t" i oznacza ograniczenie możliwości wykonywania operacji na pliku/katalogu. Tylko jego właściciel lub użytkownik z uprawnieniami roota mogą zmieniać/usuwać/przenosić taki obiekt.

Oprócz SUID/SGID problem stanowią obiekty world-writable, czyli takie, które mogą być modyfikowane przez kogokolwiek (o uprawnieniu 777). Jeżeli okazałoby się, że takim plikiem jest np. /etc/shadow, to mielibyśmy spory problem. W odnalezieniu obiektów tego typu z pomocą po raz kolejny przychodzi polecenie find:

find / -xdev -type f -perm -0002 -print

Jeżeli będą jakieś rezultaty, można je skorygować poleceniem:

chmod o-w [nazwa_pliku]

O uprawnieniach, tak jak o kontach, można mówić znacznie więcej. Zasygnalizujmy tylko kwestie, na które warto zwrócić uwagę.

W trakcie instalacji systemu tworzonych jest wiele różnych kont, co widać w pliku /etc/passwd. Należy zadbać o to, aby tylko te należące do użytkowników miały prawo zalogowania się. Na przykład nie ma potrzeby, żeby takie prawo miało konto mail:

Linux twardy jak skała

Wystarczy więc zamienić powłokę na coś, co nią nie jest (jak w powyższym przykładzie /sbin/nologin lub ulubiony /dev/null).

Kolejna sprawa to zajęcie się kontami użytkowników i aktywowanie cyklicznej zmiany haseł oraz wymuszania minimalnej długości hasła poprzez modyfikację parametrów PASS_MAX_DAYS, PASS_MIN_DAYS, PASS_MIN_LEN oraz PASS_WARN_AGE w pliku /etc/login.defs. Warto także przy okazji ustawić banery, które będą ostrzegały użytkowników przed konsekwencjami nieuprawnionego wykorzystywania systemów.

Można również modyfikować uprawnienia folderów użytkowników tak, aby jeden nie widział zawartości folderu drugiego (co powinno być ustawieniem domyślnym).

Kończąc kwestię uprawnień, trzeba także przejrzeć konfigurację SUDO (superuser do) - mechanizmu, który umożliwia wykonywanie przez użytkowników zadań z uprawnieniami kogoś innego (najczęściej roota). Jest ona przechowana w /etc/sudoers. Do edycji tego pliku najlepiej wykorzystać zmodyfikowaną wersję edytora vi, czyli visudo.


TOP 200