Najprostszym pomysłem na poprawienie bezpieczeństwa serwerów uniksowych jest zastosowanie polecenia
chroot (lub podobnego).
Pozwala ono uruchomić program (najczęściej jakiegoś demona) w klatce - to znaczy tak, że katalogiem
/ procesu będzie jakiś inny katalog (na przykład /srv/bind).
W ten sposób nawet jeżeli zabezpieczenia procesu zostaną złamane i atakujący otrzyma uprawnienia roota,
to nie będzie w stanie zmodyfikować ważnych plików systemowych (ponieważ nie będzie ich widział).
Przykładowo
$ chroot /srv/bind /bin/bind
spowoduje zmianę / na /srv/bind (oczywiście tylko dla tego procesu i jego potomków)
i uruchomienie /srv/bind/bin/bind (po zmianie po prostu /bin/bind) w takiej klatce.
Ponieważ teoretycznie atakujący nie wie, że jest w klatce a nie w prawdziwym systemie, próbowano zastosować chroot do konstrujcji honeypotów i innych pułapek na włamywaczy. Jednak dość szybko z tego zrezygnowano - ponieważ istnieją pewne przesłanki do tego żeby intruz (jeżeli jest dostatecznie sprytny) zorientował się że znajduje się w pułapce - na przykład
$ ls -id / 2 / $ ls -id /srv/bind 1624111 /srv/bind
(numer i-węzła prawdziwego / jest zawsze niski - typowo 1 albo 2 - a numer i-węzła klatki będzie
z dużym prawdopodobieństwem wysoki).
Niewątpliwie to ciekawe rozwiązanie pozwala uchronić się przed błędami w niektórych demonach. Nie jest ono jednak zbyt wygodne, ponieważ wszystkie potrzebne do działania demona pliki także trzeba przenieść do klatki - w tym biblioteki dynamiczne, pliki konfiguracyjne i tak dalej - czego nie wspiera domyślnie większość systemów (w tym popularne dystrybucje Linuksa). Sposobu tego nie można również bezpośrednio zastosować do demonów używanych do serwowania plików użytkownika (ponieważ muszą one mieć dostęp do tych plików). Do tego trzeba bardzo uważać na linki prowadzące z klatki na zewnątrz, ponieważ mogą one pozwolić atakującemu z niej uciec. (Niestety domyślna linuksowa implementacja chroota pozwala rootowi z niego uciec lub szkodzić systemowi nawet ze środka - na przykład zabijając ważne procesy. Ten problem usuwają niektóre łatki na jądro. Można też po wejściu do klatki zmienić użytkownika na nieuprzywilejowanego - zostawiając ewentualnie część uprawnień za pomocą capabilities.)
Mimo tych wad rozwiązania podobne do chroota - na przykład jail w BSD - są dość
często używane, szczególnie tam gdzie bezpieczeństwo jest ważniejsze niż wygoda administratora.