Jak ograniczyć powłokę użytkownika, umożliwiając wykonywanie programów powłoki

Czy można zapobiec temu, aby użytkownik nie używał poleceń takich jak ls, rm i innych poleceń systemowych, które mogłyby uszkodzić system. Ale użytkownicy powinni mieć możliwość wykonywania programów powłoki.

Twoje pytanie powinno brzmieć:

Nie ufam moim użytkownikom. Głupi widzą coś w Internecie i wypróbowują to, nie rozumiejąc, co robi. Przebiegli lubią węszyć i patrzeć na pliki innych ludzi i kraść ich pomysły. I leniwi, nie zaczynajcie od leniwych.

Jak chronić system i użytkowników przed użytkownikami?

Po pierwsze, unix ma bardzo kompleksowy system uprawnień do systemu plików. Wydaje się, że jest to przyzwoity samouczek dotyczący uprawnień systemu plików w systemie Unix . Istotą tego jest to, że katalogi można ustawić tak, aby użytkownik mógł wejść do katalogu i uruchomić programy poza tym katalogiem, ale nie mógł wyświetlić zawartości tego katalogu. Jeśli to zrobisz, na przykład na / home, jeśli użytkownik uruchomi ls na / home, otrzyma błąd odmowy uprawnień.

Jeśli naprawdę boisz się swoich użytkowników i chcesz umieścić ich w ograniczonym środowisku supermax , użyj czegoś takiego jak więzienia Freebsd lub strefy Solaris - każdy użytkownik otrzymuje własne, dostosowane do potrzeb środowisko. Aby uzyskać dodatkowe punkty, użyj ZFS, abyś mógł zrobić migawkę środowiska podczas logowania, więc jeśli usuną swoje pliki, możesz po prostu wyciągnąć je z migawki.

Istnieją trzy rzeczy, które muszą być na miejscu, aby w pełni wykonać to, o co prosisz:

1. Niestandardowa powłoka, której brakuje poleceń, którymi jesteś zainteresowany . Jest to trudne, ale jeśli naprawdę nie chcesz, aby użytkownicy mieli dostęp do niektórych prymitywów powłoki, jest to jedyny sposób na ich usunięcie.
2. Poprawnie ustaw uprawnienia do pliku . Nie chcesz, aby użytkownicy uszkadzali system? Ustaw uprawnienia, aby nie uszkodziły systemu, nawet jeśli mają odpowiednie narzędzia. Z tych trzech kroków jest to najłatwiejszy krok.
3. Użyj obowiązkowej technologii kontroli dostępu, takiej jak AppArmor . MAC takie jak AppArmor i SELinux osadzają uprawnienia w jądrze. Uniemożliwiają one użytkownikom uruchamianie odpowiednich narzędzi, nawet jeśli gdzieś je znajdą (i podobnie jak uprawnienia do plików, uniemożliwiają korzystanie z nich poza ograniczonym polem).

Pasek, szelki i zszywacz na wszelki wypadek. Trudno się tam pomylić.

AppArmor jest interesujący, ponieważ MAC dla określonego pliku wykonywalnego jest dziedziczony przez wszystkie jego dzieci. Ustaw login użytkownika na /bin/bash-bob, ustaw profil AppArmor dla tego konkretnego prawa binarnego, a jedynym sposobem, w jaki wydostaną się z tego więzienia, są exploity jądra. Jeśli jakiś leniwy skrypt instalacyjny pozostawił /var/opt/vendor/tmpmożliwość zapisu globalnego z jakiegoś głupiego powodu, użytkownik używający go /bin/bash-bobjako powłoki nie będzie mógł tam pisać . Ustaw profil bash-bob, aby zezwalał tylko na zapis do katalogu domowego /tmp, a takich błędów uprawnień nie można wykorzystać. Nawet jeśli w jakiś sposób znajdą hasło roota, profil AppArmor /bin/bash-bobbędzie obowiązywał nawet po tym, jak susię pojawią, sua bashproces jego odradzania jest potomkiem /bin/bash-bob.

Trudność polega na budowaniu tego profilu AppArmor.

1. Utwórz profil AppArmor dla / bin / bash-bob i ustaw go w trybie inspekcji
2. Ustaw powłokę logowania Boba na / bin / bash-bob
3. Zaloguj się jako Bob. Zrób wszystko, co chcesz, aby Bob mógł zrobić.
4. Użyj dziennika kontroli, aby zbudować profil AppArmor (SUSE ma do tego odpowiednie narzędzia, nie jestem pewien co do innych dystrybucji Linuksa). Jest to potwornie nużące, ale musi się zdarzyć, jeśli potrzebujesz tego poziomu bezpieczeństwa.
   1. Będziesz robił takie rzeczy jak:
      • Zatwierdzanie dostępu do odczytu do większości bibliotek systemowych
      • Zatwierdzanie praw do odczytu i wykonywania wybranych wybranych dozwolonych poleceń systemowych
      • Zatwierdzanie dostępu do zapisu do przestrzeni tymczasowych
      • Zatwierdzanie tworzenia gniazda, jeśli to konieczne
5. Ustaw zasady w celu wymuszenia.
6. Zaloguj się jako Bob, rób rzeczy.
7. Wprowadź zmiany.

Moim zdaniem potrzebujesz tylko kroków 2 i 3, ponieważ w połączeniu oba zapobiegają możliwości robienia czegokolwiek szkodliwego poza starannie skonstruowanym pudełkiem, które ustawiłeś w obu tych krokach.

Cóż, możesz ustawić powłokę użytkownika na napisany program, który pozwala tylko na uruchamianie określonych skryptów powłoki.

Oczywiście byłoby to tak bezpieczne, jak program i skrypty powłoki; w praktyce ten rodzaj ograniczonej powłoki zwykle nie jest zabezpieczony przed inteligentnym atakującym.

Nie próbuj ograniczać poleceń, ograniczaj uprawnienia do plików. Nie można praktycznie ograniczyć dostępu ludzi do wywołań systemowych, więc wszystko, co ktoś musi zrobić, to dostarczyć własną kopię „niebezpiecznych” poleceń, których nie chcesz, aby były wykonywane, a ty jesteś wypchany.

Jeśli chcesz, aby użytkownik mógł wykonywać tylko niektóre skrypty / pliki binarne, możesz użyć ograniczonej powłoki . To (jak wspomina artykuł z Wikipedii) nie jest całkowicie bezpieczne, ale jeśli możesz zagwarantować, że żadna aplikacja, której zezwolenie na uruchomienie nie jest w stanie wykonać nowej powłoki, jest dobrą alternatywą.

Aby ustawić powłokę ograniczoną przez użytkowników, ustaw /bin/rbash(lub podobnie, większość powłok wchodzi w tryb ograniczony, gdy nazwa pliku binarnego to r *** name *) jako powłoka użytkownika. Następnie edytuj **. Bashrc (lub odpowiednik) i ustaw $PATHkatalog, w którym przechowywane są wszystkie dozwolone pliki binarne / skrypty.

Tak, jest to możliwe, ale w praktyce wymagałoby to dużo pracy i planowania. Możesz tworzyć skrypty i uruchamiać je jako uprzywilejowane użycie, a następnie usunąć wszystkie uprawnienia z danego użytkownika. Lub możesz ustawić powłokę użytkownika na coś własnego, co pozwala mu robić tylko to, na co wyraźnie zezwalasz.

Jednak standardowe uprawnienia w systemie Linux sprawiają, że normalny użytkownik prawie nie może „uszkodzić systemu”. Jakiej szkodzie próbujesz zapobiec? To trywialne, aby uniemożliwić użytkownikom instalowanie oprogramowania lub uruchamianie programów poza ich katalogiem domowym, a za pomocą chroot można jeszcze bardziej zablokować system.

Możesz wypróbować [lshell] [1] (ograniczona powłoka).

lshell to powłoka zakodowana w języku Python, która pozwala ograniczyć środowisko użytkownika do ograniczonych zestawów poleceń, włączyć / wyłączyć dowolne polecenie przez SSH (np. SCP, SFTP, rsync itp.), rejestrować polecenia użytkownika, wdrażać ograniczenia czasowe, i więcej.

[1]: http://lshell.ghantoos.org/Overview lshell

Sposób, w jaki zwykle wdrażam tego rodzaju ograniczenia, wymaga spełnienia kilku warunków, w przeciwnym razie ograniczenie można łatwo obejść:

• Użytkownik nie należy do wheelgrupy, która jest jedyną osobą upoważnioną do korzystania su(wymuszoną przez PAM).

• Użytkownik otrzymuje odpowiednio zabezpieczone, rbash tylko PATHdo odczytu, wskazujące na prywatny ~/bin, ten ~/bin/katalog zawiera linki do prostych narzędzi:

  $ ll ~/bin
  total 0
  lrwxrwxrwx. 1 root dawud 14 Sep 17 08:58 clear -> /usr/bin/clear*
  lrwxrwxrwx. 1 root dawud  7 Sep 17 08:58 df -> /bin/df*
  lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 egrep -> /bin/egrep*
  lrwxrwxrwx. 1 root dawud  8 Sep 17 08:58 env -> /bin/env*
  lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 fgrep -> /bin/fgrep*
  lrwxrwxrwx. 1 root dawud  9 Sep 17 08:58 grep -> /bin/grep*
  lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 rview -> /bin/rview*
  lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 rvim -> /usr/bin/rvim*
  lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 sudo -> /usr/bin/sudo*
  lrwxrwxrwx. 1 root dawud 17 Sep 17 08:58 sudoedit -> /usr/bin/sudoedit*
  lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 tail -> /usr/bin/tail*
  lrwxrwxrwx. 1 root dawud 11 Sep 17 08:58 wc -> /usr/bin/wc*
  

• użytkownik otrzymuje ograniczoną, tylko do odczytu środowiska (myślę o takich rzeczach LESSSECURE, TMOUT, HISTFILEzmiennych).

• użytkownik jest mapowany na użytkownika SELinux staff_ui otrzymuje uprawnienia do wykonywania poleceń tak jak inny użytkownik zgodnie z wymaganiami za pośrednictwem sudo.

• użytkownik i możliwe /home, /tmpże /var/tmpjest on polinstantified poprzez /etc/security/namespace.conf:

  /tmp       /tmp/.inst/tmp.inst-$USER-     tmpdir:create   root
  /var/tmp   /tmp/.inst/var-tmp.inst-$USER- tmpdir:create   root
  $HOME      $HOME/$USER.inst/              tmpdir:create   root
  

  Ponadto /etc/security/namespace.initsprawia , że wszystkie pliki szkieletowe są tylko dla użytkownika i są własnością root.

W ten sposób możesz wybrać, czy $USERmożesz wykonać dowolne polecenie we własnym imieniu (poprzez link w prywatnym ~/binkatalogu, udostępnionym przez /etc/skel, jak wyjaśniono powyżej), w imieniu innego użytkownika (przez sudo), czy też wcale.

Tak, wystarczy zmienić uprawnienia do tych poleceń.

Możesz mieć większą szansę na walkę, pisząc polecenie powłoki, które zachowuje się zgodnie z Twoimi wymaganiami.

Co nie jest odpowiednie z domyślnych uprawnień dla zwykłych użytkowników w systemie Linux?