A

dministrator systemu dysponuje kontem o nazwie root, posiadającym wszelkie uprawnienia i możliwość kontroli plików, katalogów, kont użytkowników i sieci. Zarządza on kontami poszczególnych użytkowników, grupami roboczymi i systemem plików. Każde konto otrzymuje swoje uprawnienia – oddzielną nazwę, oddzielne hasło, oddzielnie definiowany dostęp do plików i usług.

Najpierw mamy do czynienia z pojedynczymi użytkownikami, lecz podczas zakładania im kont łączy się ich w grupy zgodnie z zadaniami, które będą wykonywać lub ze względu na potrzebny im zakres dostępu do danych lub urządzeń. Oczywiście, istnieje też możliwość operacji na całych grupach użytkowników. Jeśli użytkownik przekroczy swoje uprawnienia, administrator może jednym poleceniem zablokować mu dostęp do systemu bez naruszania warunków i komfortu pracy innych. Każdy użytkownik posiada własny katalog domowy i może tworzyć pliki, katalogi oraz dokonywać innych zmian tylko w jego obrębie. Reszta systemu powinna pozostawać “tylko do odczytu” (z pewnymi wyjątkami np. katalogiem /tmp), a do niektórych zasobów użytkownik nie powinien mieć żadnego prawa, co jest bardzo dobrym rozwiązaniem zapewniającym, że nikt niepowołany nie może zmodyfikować krytycznych elementów systemu. Dzięki takiemu podejściu użytkownicy są też odseparowani od siebie nawzajem – ich działania ze sobą nie kolidują. Natomiast użytkownik root posiada zawsze całkowitą i niepodważalną władzę – może kontrolować, z jakich zasobów każdy z użytkowników korzysta lub, które pliki wolno mu odczytać / wykonywać.

  Powyższa dyskusja może doprowadzić do błędnego wniosku, iż musimy ustalać prawa dostępu do każdego pliku. Na szczęście podczas instalacji – Linux sam ustali prawa dostępu do plików systemowych (dokładniej rzecz ujmując, Linux rozpakowuje te pliki wraz z oryginalnymi prawami dostępu nadanymi im przez ich autorów). Zdarza się jednak, że uprawnienia te nie mają poprawnych wartości. Czasami programiści nadają pakietom zbyt ograniczone uprawnienia, jednak częściej uprawnienia te są zbyt szerokie (uprawnienia są zazwyczaj nadawane podczas rozpakowywania pakietu). Jak się wkrótce przekonamy, może to narazić na szwank bezpieczeństwo systemu.

Główną zaletą Linuksa jak i Uniksa są rozbudowane mechanizmy kontroli dostępu do plików i katalogów. Każdemu z użytkowników można przydzielić osobne prawa. Jeden z nich może dany plik tylko odczytać, inny może odczytać i dopisać do niego nowe dane, a jeszcze inny może w ogóle nie wiedzieć, że takie pliki istnieją. W Linuksie jak i Uniksie prawa dostępu nadajemy lub odbieramy czy też ustalamy od nowa za pomocą polecenia “chmod“. Polecenie to posiada następującą składnię:

<adresat><akcja><prawa> <plik/katalog>

Gdzie:

#Adresat – dzieli się na trzy cele, którymi mogą być:

• właściciel, czyli użytkownik danego programu, pliku lub katalogu (u – user),
• grupa, do której należy lub nie dany użytkownik (g – group),
• inni użytkownicy posiadający inne numery identyfikacyjne i należący do innych grup (o – others).

# Akcja – dzieli się na trzy czynności, którymi mogą być:

• nadanie praw (znak “+“),
• odebranie praw (znak “–“),
• ustalenie praw od nowa (znak “=“).

# Prawa dostępu – dzielą się na trzy podstawowe możliwości:

• prawo do zapisu (w – write) – umożliwia dodawanie lub usuwanie różnych informacji do lub z pliku / katalogu, zmianę jego nazwy, możliwość jego usunięcia czy przeniesienia w inne miejsce systemu,
• prawo do odczytu (r – read) – umożliwia odczyt danego pliku lub katalogu,
• prawo do wykonywania (x – eXecute) – umożliwia uruchamianie skryptów czy binarnych programów, przeszukiwanie katalogu, który posiada także prawo do odczytu.

  Dodatkowo do praw dostępu możemy dodać takie prawa jak:

  • Set User ID (s – suid) – program posiadający ustawiony ten atrybut zostanie wykonany z uprawnieniami ich właściciela nawet wówczas, gdy uruchomiony został przez innych użytkowników.
  • Set Group ID (S – sgid) – podobnie jak w przypadku atrybutu suid tylko z tą różnicą, że program z takim bitem uruchomiony przez użytkowników z innej grupy zostanie wykonany z uprawnieniami dla danej grupy.
  • Bezpieczny atrybut tekstu (t – save text attribute) – uprawnienie to stosowane jest dla wszystkich “wrażliwych” katalogów takich jak /tmp. Jego ustawienie powoduje, że pliki znajdujące się w danym katalogu mogą być usunięte tylko przez ich właścicieli lub przez właściciela katalogu. Dzięki temu można tworzyć katalogi, w których wszyscy mogą zapisywać pliki, ale nie mogą ich sobie nawzajem kasować (ograniczenie to działa nawet wtedy, gdy uprawnienia pliku ustawione są z największymi uprawnieniami).

Dla przykładu załóżmy, że plik “.login” nie posiada żadnych praw dostępu. Jednak chcemy, aby użytkownik – właściciel tego pliku miał możliwość jego wykonywania. Tak więc wydajemy komendę:

chmod u+x .login

– określamy jako cel użytkownika (u) nadając mu prawo (+) do wykonywania (x) pliku .login. Prawa pliku lub katalogu możemy odczytać za pomocą polecenia: ls -l <plik/katalog> (ls -l .login).

---x------  1  agresor  users  115  Jun  10   2003  .login - plik / katalog
||||||||||     |           |    |      \  |   /           
12345678910   użytkownik grupa objętość data utworzenia / modyfikacji

W powyższym listingu możemy zauważyć na początku dziesięć znaków. Każdy z tych znaków to jeden bit. Pierwszy bit zawsze oznacza rodzaj danego obiektu gdzie obiektem może być:

• regularny plik (-),
• urządzenie blokowe (b – block),
• urządzenie znakowe (c – char),
• katalog (d – directory),
• potok nazwany (p),
• dowiązanie symboliczne lub sztywne (l – link).

Z drugiego, trzeciego oraz czwartego bitu (pola od 2 do 4) możemy odczytać prawa dla właściciela gdzie: drugi bit (2) odpowiedzialny jest za prawo do odczytu, trzeci bit (3) za prawo zapisu i czwarty (4) za prawo do wykonywania, jeśli ustawiony jest bit suid to właśnie na jego pozycji widnieje litera “s” zamiast “x“. Kolejna trójka, czyli bity od piątego do siódmego oznaczają prawo dostępu dla grupy gdzie: piąty bit (5) jest odpowiedzialny za prawo do odczytu, szósty bit (6) za prawo do zapisu i siódmy (7) za prawo do wykonywania, jeśli ustawiony jest bit sgid to właśnie na jego pozycji widnieje litera “s” zamiast “x“. Ostatnia trójka, czyli bity od ósmego do dziesiątego oznaczają prawo dostępu dla innych użytkowników gdzie: ósmy bit (8) odpowiedzialny jest za prawo do odczytu, dziewiąty bit (9) za prawo do zapisu i dziesiąty (10) za prawdo do wykonywania, jeśli ustawiony jest bit save text attribute to właśnie na jego pozycji widnieje litera “t” zamiast “x“. Tak więc jak widzimy odczytując prawa dostępu do danego obiektu możemy podzielić je na trzy pola po trzy komórki w każdym polu, gdzie każde pole oznacza osobne prawa dla danego celu. Poddajmy analizie poniższy ciąg:

drwxrw---x  1  agresor  users  1024  Jun 10   2003   /public_html

Zakładając, że powyższy katalog nie posiada żadnych praw, a chcemy mu nadać takie same prawa jak w powyższym listingu wydajemy polecenie: chmod u+rwx,g+rw,o+x public_html. Na przykład w innej sytuacji, która zakłada, że katalog ten posiada pełne prawa dostępu dla każdego użytkownika – wydajemy polecenie: chmod o-rw public_html. Istnieje jeszcze drugi sposób modyfikacji praw. Zamiast stosowania standardowego zapisu nadawania lub odbierania praw dostępu możemy zastosować zapis w postaci liczb ósemkowych. Jeżeli chcemy bezpośrednio używać wartości ósemkowych powinniśmy je do siebie po kolei dodawać. Otrzymamy w ten sposób wypadkową liczbę, która określi nam wszystkie prawa dostępu do danego pliku lub katalogu. Stosując się do tego będziemy zdolni wyrazić wszystkie kombinacje dla właściciela, grupy lub innych użytkowników przy pomocy jednej z ośmiu wartości:

0 - brak jakichkolwiek uprawnień,
1 - prawo do wykonywania,
2 - prawo do zapisu,
3 - prawo do wykonywania i zapisu,
4 - prawo do czytania,
5 - prawo do czytania i wykonywania,
6 - prawo do czytania i zapisu,
7 - wszystkie uprawnienia razem.

Atrybuty specjalne:

1000 - odpowiada ustawieniu bitu save text attribute (t),
2000 - odpowiada ustawieniu bitu set gid (s),
4000 - odpowiada ustawieniu bitu set uid (s).

Także jak widzimy komenda w standardowym zapisie: chmod u=rwx jest równoważna z komendą w zapisie ósemkowym: chmod 700. Przyglądając się jeszcze bliżej tym dwóm zapisom można stwierdzić, że w zapisie ósemkowym adresat nadawanych lub odbieranych praw dostępu zależny jest od miejsca ulokowania danego bitu. Tak więc pierwsza liczba określa prawa dla właściciela (7), druga grupy (0) oraz trzecia innych użytkowników (0).

Zanim przejdziemy do obierania / nadawania praw, które dają nam bardzo duże pole manewru jak i dużą ilość kombinacji w kwestii bezpieczeństwa, należy pamiętać, aby zbytnio nie przesadzić z ich odbieraniem czy nadawaniem. Najlepiej przed dokonaniem jakichkolwiek zmian, zapisać w jakimś pliku tekstowym dotychczasowe prawa dostępu, aby upewnić się, że w przypadku wpłynięcia naszych zmian na poprawną pracę danego programu, a co za tym często idzie całego systemu będzie szansa przywrócenia jego stabilności. Drugą rzeczą jaka staje się bardzo pomocna jest stworzenie konta testowego o uprawnieniach zwykłego użytkownika, które pozwoli nam potwierdzić swoje założenia, co do nałożonych restrykcji. Poniżej zamieszczam przykładową listę podstawowych katalogów całego systemu, która posłuży nam jako pierwszy przykład do wykorzystania mechanizmu ograniczania praw:

drwxr-xr-x   16 root     root         1024 Nov 26 19:24 ./
drwxr-xr-x   16 root     root         1024 Nov 26 19:24 ../
drwxr-xr-x    2 root     bin          2048 Oct 15 19:13 bin/
drwxr-xr-x    2 root     root         1024 Nov 15 10:08 boot/
drwxr-xr-x   14 root     root        39936 Nov 26 19:23 dev/
drwxr-xr-x   17 root     root         2048 Nov 26 19:23 etc/
drwxr-xr-x    4 root     root         1024 Nov 26 19:23 home/
drwxr-xr-x    4 root     root         3072 Nov 15 13:09 lib/
drwx------    2 root     root        12288 Oct  4 15:25 lost+found/
drwxr-xr-x    7 root     root         1024 Oct 13 21:03 mnt/
dr-xr-xr-x   35 root     root            0 Nov 26  2003 proc/
drwx--x---   10 root     root         2048 Nov 25 10:19 root/
drwxr-xr-x    2 root     bin          4096 Nov 15 13:17 sbin/
drwxrwxrwt    9 root     root         1024 Nov 25 10:24 tmp/
drwxr-xr-x   17 root     root         4096 Sep 23 22:58 usr/
drwxr-xr-x   12 root     root         1024 Sep 23 22:58 var/

Spoglądając na prawa tych katalogów przeanalizujmy niektóre z nich pod kątem funkcji jakie pełnią one w systemie (jak widać głównym właścicielem katalogów jest administrator systemu – root, katalogi należą także do tej samej grupy i tylko w dwóch przypadkach do grupy bin, dlatego zmiana jakichkolwiek praw dostępu głównie będzie wiązała się z innymi użytkownikami).

• Katalog /boot – w tym katalogu najczęściej umieszczane są wszystkie pliki niezbędne do załadowania systemu operacyjnego (jądro systemu – kernel, mapa systemu, kopia boot sektora dysku twardego itp.), dlatego zwykli użytkownicy raczej nie powinni posiadać potrzeby wglądu w ten katalog.
• Katalog /var – przechowuje wszystkie buforowane pliki drukarek (jeśli takie posiadamy), pliki poczty elektronicznej, pliki wiadomości oraz pliki dzienników systemowych, dlatego chcąc ograniczyć do niego dostęp dla zwykłych użytkowników musimy zachować dla nich, co najmniej prawa wykonywania.
• Katalog /home – w katalogu tym standardowo zawarte są katalogi użytkowników systemu. Jeśli chcemy dokonać na nim jakiegokolwiek ograniczenia musimy pamiętać by zachować, co najmniej prawa wykonywania.
• Katalog /sbin – w katalogu tym znajdują się wyłącznie programy, których działanie kierowane jest w stronę administratora systemu, dlatego zwykli użytkownicy nie powinni posiadać jakichkolwiek praw do niego oraz korzystać wyłącznie z programów przeznaczonych dla nich znajdujących się w katalogach /bin czy /usr/bin.
• Katalog /mnt – prawa dostępu do tego katalogu zależne są od tego jakie dodatkowe urządzenia posiadamy w nim zamontowane np. jeśli mamy dodatkowy dysk, na którym znajdują się katalogi użytkowników, a w katalogu /home istnieje tylko symboliczne dowiązanie do katalogu /mnt to prawa tego katalogu powinny być takie same jak dla katalogu /home, jeśli natomiast posiadamy w nim wyłącznie zamontowany CD-ROM wraz ze stacją dyskietek czy inny napęd to możemy całkowicie ograniczyć do niego dostęp.
• Katalog /usr – sama zawartość tego katalogu wiąże się z jego podkatalogami. Możemy w nim znaleźć takie katalogi jak: bin/ – programy znajdujące się w systemie przeznaczone dla zwykłych użytkowników; doc/ – dokumentacja związana z zainstalowanymi programami oraz dokumenty HOW-TO; etc/ – pliki administracyjne; include/ – pliki nagłówkowe; lib/ – biblioteki; man/ – strony podręcznika; sbin/ – programy znajdujące się w systemie przeznaczone dla administratora; src/ – źródła jądra systemu; local/ – katalog w którym znajdują się dodatkowo zainstalowane programy przez administratora oraz ich pliki konfiguracyjne, strony podręcznika czy biblioteki. Jego wygląd strukturą jest bardzo podobny do katalogu /usr; Oprócz katalogu sbin/ oraz src/, które powinny posiadać całkowicie ograniczone prawa dla zwykłych użytkowników reszta katalogów powinna posiadać dla nich co najmniej prawo wykonywania. To samo odnosi się do katalogów znajdujących się w /usr/local.

Oto przykładowy ciąg komend, które stosują się do wyżej wymienionych wytycznych:

chmod 755 /bin
chmod 750 /boot
chmod 751 /etc
chmod 751 /home
chmod 751 /lib
chmod 751 /lib/modules
chmod 750 /mnt
chmod 750 /root
chmod 750 /sbin
chmod 755 /usr/bin
chmod 755 /usr/doc
chmod 751 /usr/etc
chmod 751 /usr/include
chmod 751 /usr/info
chmod 751 /usr/lib
chmod 751 /usr/man
chmod 750 /usr/sbin
chmod 750 /usr/src
chmod 755 /usr/local/bin
chmod 751 /usr/local/etc
chmod 751 /usr/local/games
chmod 751 /usr/local/include
chmod 751 /usr/local/info
chmod 751 /usr/local/lib
chmod 751 /usr/local/man
chmod 750 /usr/local/sbin
chmod 750 /usr/local/src

Główną zasadą podczas modyfikacji praw jest pełna świadomość jaką funkcję pełni ograniczany plik / katalog oraz jakie konsekwencje wynikną w związku z ingerencją w jego prawa. Najlepszym rozwiązaniem jest sprawdzenie działania programu przed oraz po zmianie jego praw dostępu. Odchodząc od praw dostępu do katalogów przejdzmy do praw dostępu do poszczególnych plików. Dwie ważne sprawy jakie powinny zainteresować nas na początku to nadzór nad instalowanymi i deinstalowanymi programami oraz zabezpieczenie skryptów startowych. Nie było by dobrze, gdy każdy użytkownik w naszym systemie mógłby swobodnie instalować i deinstalować programy. Dzięki takiemu przywilejowi łatwo można podmienić oprogramowanie, którego działanie może doprowadzić do przejęcia kontroli nad systemem. Jeśli z jakiś powodów nie odebraliśmy praw dostępu dla zwykłych użytkowników do programów administracyjnych znajdujących się w katalogu /sbin, to powinniśmy przynajmniej ograniczyć się do programów instalacyjnych:

chmod 700 /sbin/installpkg
chmod 700 /sbin/removepkg
chmod 700 /sbin/upgradepkg

Opcjonalnie:

chmod 700 /sbin/pkgtool
chmod 700 /sbin/makepkg
chmod 700 /sbin/explodepkg

Oraz jeśli posiadamy zainstalowany pakiet rpm.tgz:

chmod 700 /bin/rpm

Opcjonalnie:

chmod 700 /usr/bin/rpm2targz
chmod 700 /usr/bin/rpm2tgz
chmod 700 /usr/bin/rpm2cpio

Lokalizacje w powyższych wpisach możemy zastąpić komendą `which program` np. chmod 700 `which rpm`, która spowoduje automatyczną lokalizacje programu w systemie oraz odwoła do niego wynik komendy change mode. Oprócz programów związanych z instalowaniem oraz deinstalacją powinniśmy także uwzględnić katalogi, które także są z tymi operacjami powiązane. W Slackware katalogi te znajdują się w katalogu /var/log. Ich zawartość potrafi dostarczyć informacji na temat programów, które zostały zainstalowane, odinstalowane oraz uaktualnione. Informacje te na ogół nie przydają się bezpośrednio użytkownikom, dlatego dostęp do tych informacji jest dla nich zbędny:

chmod 700 /var/log/packages
chmod 700 /var/log/scripts
chmod 700 /var/log/removed_packages
chmod 700 /var/log/removed_scripts
chmod 700 /var/log/setup

Przechodząc do skryptów startowych – nie ma takiej potrzeby, aby zwykli użytkownicy mieli jakikolwiek dostęp do skryptów startowych systemów. Jedyną osobą jaka powinna posiadać możliwość zmiany ich zawartości na potrzeby systemu to administrator. Problem ten możemy rozwiązać poprzez wydanie komendy: chmod 700 /etc/rc.d/*.

Oprócz odbierania uprawnień standardowym plikom powinniśmy także zwrócić szczególną uwagę na pliki zawierające ustawiony bit suid. Zaraz po instalacji Linuksa zbyt wiele programów posiada ten bit, co może doprowadzić do naruszenia integralności bezpieczeństwa systemu. Dużo starych jak i zarówno nowych eksplolitów żeruje właśnie na tym atrybucie. Oto lista niektórych programów posiadających ustawiony właśnie ten bit po standardowej instalacji Slackware:

-rws--x--x    1 root     bin         35248 May 30  2003 /usr/bin/at
-rws--x--x    1 root     bin         10592 May 30  2003 /usr/bin/crontab
-rws--x--x    1 root     bin         29572 Jun 18  2003 /usr/bin/chfn
-rws--x--x    1 root     bin         27188 Jun 18  2003 /usr/bin/chsh
-rws--x--x    1 root     bin         34212 Jun 18  2003 /usr/bin/gpasswd
-rws--x--x    1 root     bin         20368 Jun 18  2003 /usr/bin/newgrp
-rws--x--x    1 root     bin         35620 Jun 18  2003 /usr/bin/passwd
-rws--x--x    1 root     bin        206348 May 17  2003 /usr/bin/ssh
-rwsr-xr-x    1 root     bin         14204 Jun  3  2003 /usr/bin/rcp
-rwsr-xr-x    1 root     bin         10524 Jun  3  2003 /usr/bin/rlogin
-r-sr-xr-x    1 root     bin          7956 Jun  3  2003 /usr/bin/rsh
-r-sr-xr-x    1 root     bin         10200 Jun  3  2003 /usr/bin/traceroute
-rwsr-x--x    1 root     bin         33852 Jun 18  2003 /bin/su
-rwsr-xr-x    1 root     bin         58916 Jun 22  2003 /bin/mount
-rwsr-xr-x    1 root     bin         26536 Jun 22  2003 /bin/umount
-r-sr-xr-x    1 root     bin         15004 Jun  3  2003 /bin/ping

Zwartość tej listy jest zależna od programów jakie wybraliśmy podczas instalacji systemu jak i podczas jego zarządzania. Choć liczba programów posiadających ustawiony bit suid powinna być jak najmniejsza i ograniczać się do programów, które do swojej poprawnej pracy potrzebują tego atrybutu. Dlatego przed odebraniem któregokolwiek z nich musimy się upewnić do czego służy dany program i czy ewentualne odebranie mu praw nie wpłynie negatywnie na jego pracę w systemie. Więcej informacji na temat działania oraz funkcji danego programu możemy dowiedzieć się poprzez wywołanie jego strony podręcznika – manualnej (man program) lub przeczytania dokumentacji dostarczonej wraz ze źródłami (dokumentacja programów instalowanych jako pakiety zazwyczaj znajduje się w katalogu /usr/doc). Podobnie jak w przypadku listy katalogów poddamy analizie niektóre z wyżej wymienionych programów.

• Program at – jest programem który tworzy harmonogram dla swojego demona, który uruchamia wpisane w niego polecenia w podanym przez użytkownika czasie. Jeśli nie chcemy całkowicie pozbawiać użytkowników tej usługi nie musimy odbierać mu bitu suid. Wystarczy, że stworzymy plik at.allow kasując wcześniej at.deny i umieścimy go w katalogu /etc. Wpisując do pliku at.allow nazwę użytkownika root, który jest administratorem w naszym systemie spowodujemy blokadę dostępu do tego programu dla innych użytkowników (użytkownik, który spróbuje wywołać program otrzyma komunikat: You do not have permission to use at). W ten sposób do pliku możemy dodać zaufanych użytkowników (lista powinna być tworzona poprzez pozycje jedna pod drugą) lub użytkowników, którzy udokumentowali potrzebę do posiadania dostępu do tego programu.
• Program crontab – program ten uruchamia, co pewien czas polecenia, skrypty lub programy (wiele użytkowników zapatrzonych w usługę IRC wykorzystuje go do odpalania botów). Jednak należy wiedzieć, że istnieją eksploity, które dzięki ustawionymi bitowi suid na tym programie umożliwiają uzyskanie praw administratora przez standardowego użytkownika. Poza tym nigdy nie należy pozwalać, aby jakikolwiek proces czy program odpalony przez użytkownika posiadał uprawnienia administratora. Wręcz powinno być odwrotnie to administrator powinien dążyć, aby procesy były uruchamiane z prawami zwykłych użytkowników dlatego powinniśmy usunąć bit suid z tego programu (chmod -s /usr/bin/crontab).
• Program chfn – program ten służy do zmiany danych osobowych użytkownika oraz innych informacji takich jak telefon kontaktowy itp. Ogólnie rzecz biorąc każda zmiana powinna być wcześniej skonsultowana z administratorem i tylko administrator powinien posiadać możliwość dokonywania zmian danych osobowych użytkowników w celu uniknięcia podania fałszywych informacji. Lecz jeśli chcemy, aby użytkownik posiadał możliwość tylko zmiany np. telefonu kontaktowego – pozostawiając ustawiony bit suid powinniśmy dokonać odpowiednich zmian w pliku /etc/login.defs (więcej informacji znajdziemy w artykule “Zasady logowania do systemu”). W celu całkowitego ograniczenia oczywiście usuwamy wcześniej wspomniany bit (chmod -s /usr/bin/chfn).
• Program chsh – program ten umożliwia zmianę aktualnej powłoki systemowej na inną (spis zainstalowanych powłok w systemie znajduje się w pliku /etc/shells). Jeszcze wiele powłok nie oferuje logowania historii poleceń wydawanych przez użytkowników, dlatego wyłącznie administrator powinien decydować o zmianie powłoki dla danych użytkowników, sytuacja ta staje się jeszcze bardziej wyrazna kiedy w naszym systemie zainstalowaliśmy powłokę oferującą dodatkowe logowanie poleceń (chmod -s /usr/bin/chsh).
• Programy gpasswd oraz newgrp – programy te są składowymi pakietu oferującego pełną administrację nad grupami systemowymi. Pierwszy z nich umożliwia ustalenie administratora (administratorów) grupy, który będzie miał możliwość dodawania nowych członków lub usuwania starych. Drugi newgrp – jest używany w celu zmiany aktualnego identyfikatora grupy. Jeśli planujemy lub już posiadamy system oparty na rozbudowanym systemie grup powinniśmy obydwa te programy pozostawić z dotychczasowymi prawami.
• Program passwd – w ręku administratora program służący do zmiany haseł użytkowników, blokowania oraz odblokowywania ich. W ręku zwykłego użytkownika program do zmiany własnego hasła. Program w celu prawidłowego działania powinien posiadać jak najbardziej ustawiony bit suid.
• Program ssh – jest klientem bezpiecznej sesji zdalnej. Program ten umożliwia bezpieczne połączeni ze zdalnym serwerem przy użyciu zaawansowanych algorytmów szyfrowania danych. Po wprowadzeniu nazwy użytkownika i hasła oraz udanym logowaniu na serwerze zdalnym jego działanie jest identyczne jak programu telnet (by uzyskać więcej informacji patrz artykuł “Zabezpieczanie Secure Shell”). Dla poprawnego działania dla wszystkich zwykłych użytkowników program ten wymaga ustawionego atrybutu suid.
• Program rcp – kopiuje pliki pomiędzy dwoma komputerami. Program ten umożliwia skopiowanie pliku z komputera zdalnego. Program ten jednak nie oferuje żadnej transmisji kryptograficznej, dlatego lepiej jest używać bezpieczniejszej jego odmiany – scp pochodzącej z pakietu SSH. Dlatego powinniśmy pozbawić bitu suid ten program lub nawet go usunąć (chmod -s /usr/bin/rcp lub nawet rm /usr/bin/rcp).
• Program rlogin – program ten umożliwia użytkownikowi podłączenie jego terminala do zdalnego komputera w celu podjęcia interaktywnej sesji. rlogin jest bardzo podobny w swej funkcjonalności do programu telnet – z tą istotną różnicą, że ten pierwszy pozwala na logowanie użytkowników do systemu bez podania hasła. Jest to wygodne wtedy, kiedy mamy kilka kont na maszynach w jednej sieci i chcemy uniknąć każdorazowego podawania hasła. Niemniej jednak, ze względów bezpieczeństwa nie zaleca się stosowania tej komendy, jak i świadczenia usług typu “r” w ogólności jeśli nie przemawiają za tym istotne cele użytkowe (chmod -s /usr/bin/rlogin lub nawet rm /usr/bin/rlogin).
• Program rsh – jest to kolejny program z rodziny “r”. Umożliwia realizację poleceń i plików wykonywalnych na maszynie zdalnej bądz lokalnej. W tym przypadku jak i dwóch powyższych blokujemy tą usługę ze względu na bardzo niskie możliwości bezpieczeństwa (chmod -s /usr/bin/rsh lub nawet rm /usr/bin/rsh).
• Program traceroute – program do śledzenia trasy pakietu pomiędzy dwoma hostami. Narzędzie to jest stosowane do diagnozowania problemów, bądz do lokalizacji miejsca położenia geograficznego danej maszyny. Jest to narzędzie typowo sieciowo – administracyjne, nie używane przez większość użytkowników. To od nas zależy czy usługa ta powinna być dostępna dla zwykłych śmiertelników.
• Program su – program umożliwiający zwykłemu użytkownikowi uzyskanie uprawnień administratora dzięki wpisaniu jego hasła. Odebranie mu bitu suid spowoduje, że nawet wpisane poprawnie hasło zostanie odrzucone. Jeśli chcemy ograniczyć poprawne działanie tego programu do pewnej ilości czy grupy użytkowników to powinniśmy stworzyć plik /etc/suauth, w którym powinna być umieszczona odpowiednia reguła dotycząca uprawnień korzystania z programu su. Jeśli chcemy umożliwić korzystanie z programu tylko jednemu użytkownikowi np. agresor to wpis ten powinien wyglądać następująco: ALL:ALL EXCEPT agresor:DENY. Jeśli chcemy dodać kolejnych użytkowników do tego przywileju dodajemy ich po przecinku (agresor, firedoll). Możemy także zezwolić na użytkowanie su specyficznej grupie np. wheel, w tym przypadku wpis ten przyjmuje następującą postać: ALL:ALL EXCEPT GROUP wheel:DENY. Teraz tylko użytkownicy dopisani do grupy wheel będą posiadali możliwość poprawnego używania programu su. Drugi sposób ograniczeń opisany jest dokładnie w artykule “Zasady logowania do systemu”.
• Programy mount oraz umount – programy zazwyczaj służące do montowania i odmontowywania dodatkowych, wymiennych nośników danych. Lecz nawet z ustawionym bitem suid nie pozwalają użytkownikowi na wykonanie czynności montowania (aby użytkownik posiadał takie prawo należy dopisać dodatkowe dyrektywy do pliku /etc/fstab). Jeśli nie przewidujemy możliwości zezwolenia użytkownikom na dostęp do czytników typu CD-ROM, czy dyskietka dla pewności powinniśmy te programy pozbawić bitu suid (użytkownik, który spróbuje zamontować dodatkowy napęd w naszym systemie otrzyma komunikat: mount: must be superuser to use mount).
• Program ping – program służący do weryfikacji statusu zdalnego komputera. Ping przesyła do zdalnej maszyny datagramy ECHO_REQUEST, aby otrzymać od niej odpowiedz. Używając tego programu mamy możliwość sprawdzenia, czy dany host jest osiągalny. Jest to polecenie typowo sieciowe i podobnie jak w przypadku polecenia traceroute od nas zależy czy użytkownicy powinni posiadać do niego dostęp.

Analogicznie postępujemy z programami, które posiadają ustawiony bit set group id. Choć programów tych jest znacznie
mniej niż w przypadku programów posiadających bit set user id to nie należy zapominać, że programy te także mogą
stanowić zagrożenie dla naszego systemu. Oto lista programów z wyżej wymienionym bitem sgid zaraz po instalacji
systemu (ich ilość oczywiście zależy od wyboru programów jakiego dokonaliśmy podczas instalacji):

/usr/bin/wall
/usr/bin/write

• Program wall – służy do przekazywania wiadomości wszystkim zalogowanym użytkownikom w systemie. Składnia tego programu wymaga podanie pliku, z którego ma zostać odczytany dany komunikat. Jak możemy przeczytać w podręczniku manualnym programu tylko superużytkownik jest wstanie przekazać wiadomość użytkownikom, którzy wyłączyli przyjmowanie wiadomości na swoje konsole (komenda: mesg n), a czytanie wiadomości z pliku jest zabronione wtedy, gdy osoba uruchamiająca program nie jest superużytkownikiem i program posiada ustawiony bit suid lub sgid. Więc wynika z tego, że w tym przypadku bit sgid jest niezbędny by zwykli użytkownicy nie posiadali możliwości w pełni wykorzystania programu (zdjęcie bitu sgid spowoduje, że użytkownicy będą posiadali możliwość czytania wiadomości znajdujących się w danym pliku oraz wysyłania ich na konsole – lecz wiadomość zostanie wyświetlona tylko i wyłącznie na ich konsoli).
• Program write – jest programem pozwalającym wysyłanie komunikatów przez użytkownika do pojedynczych użytkowników. Użytkownik jest w stanie odebrać wiadomość jeśli posiada włączone przyjmowanie komunikatów na aktualnie aktywną konsolę (komenda: mesg y). Odebranie mu bitu suid oczywiście spowoduje nieprawidłowe działanie dla zwykłych użytkowników. Jednak nie jest wymagane by został on wyłączony z systematycznego użytku systemu. Chyba, że ktoś nie lubi jak mu się wysyła komunikaty pochodzące z /dev/urandom (write agresor tty2 < /dev/urandom).

Jeśli chodzi o bit save text attribute – to bit ten nie jest tak często spotykany w systemie jak bity suid czy sgid, jednak jego występowanie nie wpływa negatywnie na bezpieczeństwo – wręcz przeciwnie jego działanie wpływa na podniesienie bezpiecznych obszarów zapisu w systemie. Poniżej zamieszczam listę katalogów, które powinny posiadać ustawiony ten atrybut:

/tmp
/var/tmp
/var/lock
/var/spool/mail

   Jedną z największych innowacji systemu UNIX jest przydzielenie nazw plików do urządzeń sprzętowych, dzięki czemu możliwy jest dostęp do nich w taki sposób, jakby były to zwyczajne pliki na dysku twardym. Praktycznie wszystkie pliki urządzeń znajdują się w katalogu /dev lub w jednym z jego podkatalogów. Wszystkie te urządzenia powinny należeć do użytkownika root, oraz odpowiedniej grupy, która ma posiadać także dostęp do tych urządzeń. W systemie Slackware wystarczy wydać polecenie: ls -al /dev | more – w celu analizy nazw tych grup, a następnie porównanie ich z plikiem /etc/group – by uzyskać obraz dostępu do tych urządzeń przez użytkowników. W przypadku bezpiecznego systemu zwyczajni użytkownicy nie powinni korzystać z bezpośredniego dostępu do urządzeń dyskowych, ponieważ spowodowałoby to pominięcie wszystkich zabezpieczeń systemu pliku. Należy także zablokować bezpośredni dostęp do drukarki, ponieważ mógłby on spowodować zakłócenia w działaniu buforu wydruków lpr. Obecnie używane są następujące urządzenia dyskowe: /dev/hd?* (dyski IDE), /dev/sd?* (dyski SCSI) i /dev/md?* (macierze RAID).

Użytkownicy również nie powinni korzystać bezpośrednio z urządzenia myszy. Plik tego urządzenia jest odczytywany przez programy gpm (obsługa myszy standardowej) i X; oba te narzędzia są uruchamiane z uprawnieniami użytkownika root. Plik myszy /dev/mouse jest zwykle dowiązaniem symbolicznym wskazującym urządzenie PS2 (/dev/psaux) lub port szeregowy, do którego przyłączono mysz. Użytkownicy w żadnym wypadku nie mogą mieć dostępu do większości urządzeń tty, gdyż w przeciwnym wypadku pozwalałoby to na przechwytywanie klawiszy naciskanych przez poszczególne osoby. Szeregowe urządzenia TTY zostały nazwane /dev/ttyS*, natomiast wersja z urządzeniem dialer (używanym do inicjalizacji połączeń wychodzących) nosi nazwę /dev/cua* (nowe jądra Linuksa wykorzystują tylko pliki urządzeń /dev/ttyS* z odpowiednimi poleceniami ioctl(), co powoduje, że /dev/cua* nie są w ogóle stosowane). Aby zapewnić jeszcze większe bezpieczeństwo, wiele dystrybucji Linuksa w tym Slackware obsługuje urządzenia /dev/cua* w trybie 600 z użytkownikiem i grupą uucp. W przypadku takiej konfiguracji program /usr/bin/cu (wywołanie innego systemu uniksowego) również może mieć ustawione użytkownika i grupę uucp oraz bity set-UID i set-GID. Takie ustawienia nie pozwalają użytkownikom na nieograniczony dostęp do urządzeń. Program cu wymusza blokadę plików (semafor typu muteks), dzięki czemu tylko jeden użytkownik może w danym momencie korzystać z urządzenia. Umożliwia to bezproblemową współpracę UUCP z programem cu.

Urządzenia /dev/tty[0-9]* służą do obsługi konsoli wirtualnych, czyli prostego odpowiednika systemu okien. Większość użytkowników uruchamia X’y i nie wykorzystuje konsoli wirtualnych. Jest to jednak bardzo wygodna koncepcja, którą można zastosować w czasie konfiguracji systemów. Konsole wirtualne będą przydatne również w sytuacji gdy X nie jest niezbędny lub wymaga zbyt dużo zasobów. Odnosi się to głównie do serwerów i systemów o wysokim poziomie bezpieczeństwa.

Wiele osób zapomina o urządzeniach pamięci konsoli wirtualnej – /dev/vcs[0-9]( i /dev/vcsa[0-9]*. Dzięki tym urządzeniom uzytkownicy posiadający odpowiednie uprawnienia mogą odczytywać i zapisywać pamięć zawierającą znaki. Stosowane są przy tym reguły analogiczne do tych, które wykorzystuje się w przypadku urządzeń tty. W większości dystrybucji Linuksa urządzenia pamięci konsoli wirtualnej mają prawa 620, oferujące dość wysoki poziom ochrony. Aby zapewnić maksymalne bezpieczeństwo należy ustawić prawa 600. Plik /dev/console stanowi oryginalną konsolę i powinien mieć ustawione prawa 600 w przypadku bezpiecznych instalacji.

Wiele reguł odnoszących się do innych urządzeń tty jest stosowanych również do urządzeń /dev/tty[p-z]?, czyli “strony pseudo” urządzeń pseudo tty. Jest to strona używana przez m.in. demona telnet i podobne programy do udawania terminala dla powłoki, edytora i innych programów uruchomionych w systemie serwera. Inne reguły są stosowane dla strony “sterującej” urządzeń pseudo tt, czyli /dev/pty*. W tym przypadku ustawienie prawa 666, dzięki czemu każdy może zainicjować potok pseudo tty, ale tylko jeden proces może w danym momencie otworzyć urządzenie sterujące. Oznacza to, że program próbuje otworzyć kolejne urządzenia. Jeśli pierwsze z nich jest używane, wywołanie open() zakończy się niepowodzeniem, a program przejdzie do kolejnego urządzenia. Proces ten jest powtarzany aż do momentu odszukania dostępnego urządzenia.

Urządzenie /dev/null jest czasami nazywane ujściem danych. Jeśli użytkownik nie jest zainteresowany tym, co program zwróci podczas działania, gdyż za ważne uznaje tylko skutki jego działania, można przekierować te wyniki do urządzenia /dev/null tak jakby był to zwyczajny plik. Urządzenie /dev/null zwraca kod powodzenia dla każdego wywołania zapisu, ale wszystkie dane są usuwane. Należy podkreślić, że nie istnieje żadne ryzyko wysłania zbyt dużej ilości danych do urządzenia /dev/null, dzięki czemu jego przepełnienie nie jest możliwe. Dzieje się tak, gdyż urządzenie ustawia jedynie liczbę zapisanych bajtów na wymaganą wartość, a natępnie powraca. Zapewnia to wyjątkową wydajność działania, ponieważ bufor wyników programu nie jest nawet odczytywany. Urządzenie to może być wykorzystane również jako plik wejściowy o zerowej długości, co spowoduje ustawienie liczby odczytanych bajtów na zero, przesłanie znaku EOF (End Of File – koniec pliku) i powrót. Nie ma również żadnego zagrożenia w sytuacji, gdy program odczytuje urządzenie /dev/null w tym samym czasie, kiedy inny proces przesyła do niego swoje rezultaty. Ponieważ jest to zasób dostępny dla wszystkich, powinien mieć prawa 666. Urządzenie /dev/zero przypomina /dev/null, ale w czasie odczytu zwraca bufor o wielkości żądanej przez program. W buforze umieszczane są tylko zera binarne (wartości NUL). Urządzenie to powinno mieć prawa 666 z tych samych przyczyn co w przypadku urządzenia /dev/null.

Odczyt urządzeń /dev/random i /dev/urandom powoduje zwrócenie losowych bajtów. W przeciwieństwie do rezultatów procedur biblioteki random() są to naprawdę losowe liczby, ponieważ jądro dodaje element losowaości w postaci odstępów pomiędzy klawiszami naciskanymi w konsoli i innymi rodzajami “szumu” pochodzącego ze środowiska. Odpowiednie funkcje zostały wprowadzone od jądra Linuksa 1.3.30. Urządzenia /dev/random i /dev/urandom można wykorzystać do generowania danych losowych dla aplikacji kryptograficznych. System śledzi wygenerowany szum losowy w porównaniu z liczbą odczytanych bajtów. Jeśli element losowości został w pełni wykorzystany, odczytywany będzie blok /dev/random aż do momentu, w którym zostaną odebrane nowe czynniki losowości. W takiej sytuacji urządzenie /dev/urandom generuje dane pseudolosowe. Ponieważ oba urządzenia powinny być dostępne w trybie tylko do odczytu, należy ustawić dla nich prawa 644.

Użytkownicy nie powinni mieć dostępu do urządzeń /dev/mem (pamięć fizyczna) i /dev/kmem (pamięć jądra), ponieważ pozwalają one na uzyskanie dostępu do pamięci głównej systemu (RAM). Oba urządzenia powinny należeć do użytkownika root i grupy kmem, a ich prawa należy ustawić na 600. Także w większości przypadków nie należy przyznawać zwyczajnym użytkownikom dostępu do pozostałych urządzeń, aczkolwiek istnieje kilka wyjątków od tej reguły. Odnosi się to przede wszystkim do możliwości odczytu i zapisu dyskietek (/dev/fd*). W niektórych dystrybucjach urządzenia tego typu mają prawa 666, podczas gdy w innych stosowane są prawa 660 w połączeniu z grupą floppy. Użytkownicy mający prawa do korzystania ze stacji dyskietek są członkami grupy floppy w /etc/gorup. W podobny sposób można przyznać użytkownikom prawa do wykonania archwizacji i przywrócenia własnych danych z napędu taśmowego. Jeśli obawiamy się, że użytkownicy mogą nielegalnie kopiować dane, powinniśmy ustawić prawa 600 dla stacji dyskietek, napędów taśmowych oraz wszystkich nagrywarek CD-R. Napęd CD-ROM jest zwykle dostępny poprzez plik /dev/scd* (napędy SCSI) lub /dev/hd* (urządzenia IDE). Do montowania płyt ISO 9660 wymagane są uprawnienia root, aczkolwiek odpowiednie prawa można przyznać również zwykłym użytkownikom. Użycie przełącznika -o w pliku /etc/fstab oznacza, że użytkownik może zamontować płytę CD-ROM z pewnymi ograniczeniami.

Oto przykładowy ciąg komend, które stosują się do wyżej wymienionych wytycznych:

chmod 600 /dev/hd?*
chmod 600 /dev/sd?*
chmod 600 /dev/md?*
chmod 600 /dev/mouse
chmod 600 /dev/psaux
chmod 600 /dev/ttyS*
chmod 600 /dev/cua*
chmod 600 /dev/tty[0-9]*
chmod 600 /dev/vcs*
chmod 600 /dev/tty[p-za-e]?
chmod 600 /dev/fd*
chmod 600 /dev/lp*
chmod 600 /dev/ftape
chmod 600 /dev/st*
chmod 600 /dev/audio
chmod 600 /dev/mem
chmod 600 /dev/kmem
chmod 644 /dev/random
chmod 644 /dev/urandom
chmod 666 /dev/pty[p-za-e]?
chmod 666 /dev/tty
chmod 666 /dev/null
chmod 666 /dev/zero

Podsumowując prawa dostępu należy wspomnieć, że wytyczne przedstawione w powyższych przykładach są tylko i wyłącznie przykładami zastosowania rygorystycznych ograniczeń w stosunku, co do użytkowników systemu, które mają na celu zwiększenie poziomu bezpieczeństwa systemu. Nie jest powiedziane, że ustawienia te należy przyjmować za podstawowe. Ograniczenia w stosunku, co do swoich użytkowników należy stosować według własnych uznań. Lecz należy pamiętać o zapisaniu poprzedniego stanu systemu przed dokonaniem jakichkolwiek zmian, przetestowaniu ich na koncie zwykłego użytkownika oraz sprawdzenie w przypadku programu / urządzenia jego działanie przed oraz po zastosowaniu restrykcji.

Oprócz blokady praw dostępu możemy także zastosować blokadę ważnych plików przed zmianami. Metoda ta polega na zabezpieczeniu plików, które z punktu widzenia systemu są newralgicznie. W tym celu możemy wykorzystać bit zabraniający dokonywania jakichkolwiek zmian (+i – immutable). Wykonujemy to poleceniem “chattr” o składni: chattr +i <plik> gdzie takim plikiem może być np. /etc/passwd czy /etc/shadow, co spowoduje braku możliwości dodawania nowych użytkowników dopóki bit ten nie zostanie zdjęty. Informacje o obecności tego bitu możemy odczytać poprzez użycie polecenia: lsattr <plik>. Jedynym minusem tego rozwiązania jest monotoniczność nakładania oraz ściągania tego bitu z danego pliku w celu dokonania w nim zmian. Poniżej zamieszczam listę plików, dla których zalecany jest ten bit:

/etc/passwd
/etc/shadow
/etc/profile
/etc/exports
/etc/hosts.equiv
/etc/inetd.conf (xinetd.conf)
/etc/lilo.conf
/etc/login.access
/etc/login.defs
/etc/protocols
/etc/securetty
/etc/services

Do powyższej listy możemy dodać także pliki konfiguracyjne demonów, których instalacja oraz konfiguracja w naszym systemie pozostaje niezmienna i została zakończona jakiś czas temu. Jak już wspomniałem główną zaletą Linuksa jak i Uniksa są rozbudowane mechanizmy kontroli dostępu do plików i katalogów. W dodatku w obydwu tych systemach możemy określić z jakimi prawami będą tworzone nowo powstałe pliki. Za określenie tych praw odpowiedzialna jest zmienna umask używana przez funkcję open w celu ustawienia praw dostępu do nowo powstałego pliku / katalogu. Prawa te określamy bardzo podobnie jak w przypadku zmiany ich komendą chmod, tylko z tą różnicą, że są one odejmowane od standardowej wartości praw dostępu w wyniku czego otrzymujemy prawa z jakimi ma być tworzony nowy obiekt. Dla przykładu wartość umask standardowo równa jest 022, aby obliczyć z jakimi prawami są tworzone nowe obiekty wystarczy odjąć wartość 022 od wartości 666, co daje nam w zapisie ósemkowym wynik: 644, w zapisie standardowym jest to -rw-r–r–. Jeśli chcemy zastosować bardziej ograniczone prawa z jakimi będzie określony nowo tworzony plik możemy zmienić wartość umask z 022 na 066 (komenda: umask 066; 666 – 066 = 600).

W przypadku kiedy jesteśmy pewni swoich przetestowanych ustawień dla pewności ich niezmienności możemy wybrane ustawienia dodać do skryptów startowych dla pewności, że dane restrykcje będą inicjowane za każdym startem systemu i w przypadku ich zmiany zostaną przywrócone. W przypadku praw bazujących na komendach chmod oraz chattr może to być np. plik /etc/rc.d/local, jeśli natomiast chodzi o ustawienie zmiennej umask to jej standardowa wartość znajduje się w pliku /etc/profile oraz login.defs – poprzez ich edycję możemy wprowadzić nową wartość, która odwoływana będzie do każdego użytkownika systemu.

Bonus:Listę plików z atrybutem suid możemy odnalezć poprzez polecenie:

find / -perm +4000 > pliki_suid.txt

Listę plików z atrybutem sgid możemy odnalezć poprzez polecenie:

find / -perm +2000 > pliki_sgid.txt

Listę katalogów z atrybutem save text możemy odnalezć poprzez polecenie:

find / -perm +1000 > katalogi_save.txt

Listę plików nie należących do nikogo możemy odnalezć poprzez polecenie:

find / -nouser -o -nogroup > pliki_nobody.txt

Listę plików, które posiadają prawo zapisu dla grupy i innych użytkowników:

find / -perm -2 -o -perm -20 > pliki_zapis.txt

Program man jest wykorzystywany do wyświetlania rozdziałów z podręcznika systemu Linux. Jest to bardzo przydatne narzędzie. Program ten został tak usprawniony, że w przypadku sformatowania strony zostanie ona zachowana właśnie w takiej, sformatowanej postaci. Następnym razem, kiedy jakiś użytkownik będzie chciał wyświetlić tę stronę, program man w szybki sposób przekopiuje zachowaną wcześniej jej wersję. W przypadku wielu wersji systemu Linux, wersja sformatowana jest przechowywana w postaci skompresowanej, w celu zmniejszenia zajmowanego obszaru na dysku. W wielu systemach także katalogi, w których przechowywane są te tymczasowe pliki zawierające sformatowane strony, mają prawa dostępu równe 777, a pliki są tworzone z prawami 644 i ich właścicielem jest użytkownik, który po raz pierwszy użył programu man w stosunku do danej strony. Oczywiście nie trzeba wyjaśniać, że to umożliwia użytkownikom umieszczanie w tych katalogach tymczasowo losowych plików bez nadzoru administratora, jakiegokolwiek ostrzeżenia czy ograniczenia. W celu rozwiązania tego problemu należy wyłączyć funkcję zachowywania przetworzonych stron, poprzez blokadę / usunięcie katalogu cat:

chmod 700 /var/man/cat*

Lub bardziej drastyczny sposób:

cd /tmp
rm -rf /var/man/cat*
rm /usr/man/cat*

Jak już mówiłem – dla każdej strony podręcznika (manX) program man będzie usiłować umieścić sformatowaną wersję w katalogu (catX) pod warunkiem, że katalog ten będzie istnieć. Również w przypadku istnienia tego katalogu program ten będzie poszukiwać istniejącej sformatowanej kopii strony. Po zastosowaniu jednej z wyżej wymienionych konwencji program man nie będzie już podejmować prób tworzenia wspomnianych plików i katalogów. Zmiana bieżącego katalogu na /tmp ma na celu zminimalizowanie skutków umieszczenia spacji przed znakiem *.

Więcej informacji: man chmod, man chattr, man umask, man find