Mimo prostoty i oczywistości tradycyjnego modelu uprawnień, w systemach, do których dostęp ma wielu użytkowników, należy zachować specjalne środki ostrożności przy zarządzaniu systemem plików. Postaram się przedstawić najważniejsze z nich.
O bezpieczeństwo dobrze jest zadbać już na etapie projektowania struktury systemu plików. Przede wszystkim należy podzielić go na części (ulokowane na osobnych urządzeniach blokowych). Minimalny bezpieczny podział powinien obejmować:
/ - główna część systemu plików, tu znajdują się wszystkie programy,/var - miejsce na logi systemowe, pliki blokad podsystemów i inne,/tmp - katalog na pliki tymczasowe,/home - przestrzeń dla użytkowników.Taki podział zwiększa bezpieczeństwo między innymi dlatego, że nie można tworzyć, potencjalnie niebezpiecznych, twardych dowiązań do plików pomiędzy różnymi systemami. Do tego, na przykład, rosnące ponad miarę logi nie mogą (przez przypadek lub w wyniku jakiegoś ataku) zająć miejsca reszcie systemu.
Oprócz tego możliwe jest odebranie poszczególnym poddrzewom niepotrzebnych uprawnień, co może znacznie utrudnić
działanie standardowych wirusów, robaków i eksploitów a nawet niezbyt doświadczonych hakerów.
Wykorzystując opcje montowania, powinniśmy odebrać możliwość wykonywania programów (noexec),
uznawania bitów SUID/SGID (nosuid), interpretowania specjalnych plików urządzeń (nodev)
oraz włączyć zarządzanie limitami dyskowymi dla użytkowników (usrquota).
Bardzo dobrze (chociaż dość brutalnie) jest to rozwiązane na zodiacu:
$ mount /dev/sda2 on / type ext2 (rw) none on /proc type proc (rw,gid=17) sysfs on /sys type sysfs (rw) selinuxfs on /selinux type selinuxfs (rw) /dev/sda5 on /usr type xfs (rw,nodev) /dev/sda6 on /tmp type ext2 (rw,noexec,nosuid,nodev,usrquota) /dev/sda7 on /var type ext2 (rw,noexec,nosuid,nodev) /dev/sda8 on /var/log type ext2 (rw,noexec,nosuid,nodev) /dev/sda9 on /var/lib/rpm type ext2 (rw,noexec,nosuid,nodev) /dev/sda10 on /var/spool type ext2 (rw,noexec,nosuid,nodev) /dev/mapper/vg_home-lvol1 on /home type xfs (rw,noexec,nosuid,nodev,usrquota,logbufs=8) tmpfs on /var/spool/amavis/runtime type tmpfs (rw,size=256M,mode=750,uid=97,gid=116) none on /dev/pts type devpts (rw)
/tmp
Szczególną uwagę, zarówno administratorzy jak i programiści, powinni zwrócić na katalog /tmp.
Jest on niebezpieczny ponieważ standardowo pliki mogą tworzyć tam wszyscy użytkownicy, co przy ustawieniu
złych praw albo nieostrożnym programowaniu może doprowadzić do sytuacji wyścigu, które odpowiednio wykorzystane,
mogą w skrajnych przypadkach dać złośliwemu użytkownikowi uprawnienia roota.
Przede wszystkim katalog /tmp i podobne powinny mieć ustawiony bit sticky!
Bez niego każdy użytkownik może kasować plik tymczasowy każdego innego i tym samym utrudniać mu pracę.
Oprócz tego sprytny użytkownik może wykorzystać brak tego bitu do ataku na którąś z aplikacji uruchamianych
przez administratora.
W każdym normalnym systemie wywodzącym się z Uniksa katalog /tmp ma ten bit domyślnie ustawiony.
Jednak administratorom zbyt często zdarza się go zgubić, gdy tworzą własny katalog dla plików
tymczasowych (na przykład na innej partycji), a /tmp jest po prostu linkiem do niego.
Prawidłowe uprawnienia do katalogu /tmp powinny wyglądać tak:
$ ls -ald /tmp drwxrwxrwt 102 root root 12288 sty 10 03:27 /tmp
(t zamiast x w uprawnieniach dla innych oznacza właśnie włączony bit sticky).
Po drugie katalog /tmp powinien być montowany lokalnie, a w żadnym wypadku nie przez NFS!
(Ponieważ NFS nie honoruje flagi O_EXCL w wywołaniu systemowym open, której używa większość
funkcji służących do bezpiecznego tworzenia plików tymczasowych w /tmp.)
Dość ważna jest też kwestia okresowego czyszczenia tego katalogu.
Czyszczenie oczywiście powinno być wykonywane - w przeciwnym razie pliki tymczasowe szybko pochłoną każdą
ilość dostępnego miejsca.
Jednak najlepiej przeprowadzać je przy uruchamianiu systemu - ponieważ wtedy nie działają żadne procesy
użytkowników, które mogłyby potencjalnie utrudniać to zadanie.
(Parę lat temu znaleziono kilka luk w popularnym odśmiecaczu /tmp zwanym tmpwatch,
które odpowiednio wykorzystane mogły prowadzić co najmniej do ataków typu DoS.
Nie należy również zapominać, że ten program z konieczności działa z uprawnieniami roota!)