SELinux - CentOSx86_64: ograniczenie komend użytkownika

1

SELinux - CentOSx86_64: ograniczenie komend użytkownika

Czy SELinux jest odpowiednim narzędziem do tego zadania? Jeśli tak, jaki jest najlepszy sposób?

Chciałbym ograniczyć konkretnego użytkownika do uruchamiania tylko niektórych wstępnie zdefiniowanych poleceń / skryptów (być może w ich katalogu domowym). Ponadto skrypty użytkowników mogą mieć uprawnienia do uruchamiania poleceń, których użytkownik nie może uruchomić bezpośrednio (np. Skrypt użytkownika test.sh może wywołać „ping localhost”, ale użytkownik nie może wywołać „ping localhost” bezpośrednio z wiersza poleceń). Warto wspomnieć, że uważam, że te ograniczenia są wymagane tylko dla jednego konta użytkownika (nie będę potrzebował wielu różnych konfiguracji dla różnych kont użytkowników).

System operacyjny to CentOSx86_64, a SELinux jest włączony w następujący sposób:

SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        targeted

Jestem bardzo nowy w SELinux, ale eksperymentowałem z następującymi elementami:

(1) Pomyślałem, że polityka MLS najlepiej będzie pasowała (ten link wyglądał obiecująco: http://www.centos.org/docs/5/html/Deployment_Guide-en-US/sec-mcs-getstarted.html ) do tego zadania, więc najpierw próbowałem to włączyć. „Graficzny interfejs administratora SELinuksa” nie zawiera żadnej opcji zmiany polityki z docelowej, więc próbowałem bezpośrednio zmienić / etc / selinux / config. Zakończyło się to „paniką jądra” po ponownym uruchomieniu, więc zdecydowałem się użyć oryginalnej zainstalowanej polityki (tj. Ukierunkowanej).

(2) Z graficznego interfejsu administratora SELinux utworzyłem nową politykę z typem polityki „Minimalna rola użytkownika terminala”. Dla „imienia” nazwałem go „ograniczonym użytkownikiem”. Nie wybrałem żadnych ról, do których miałoby zostać przeniesione. Nie wybrałem żadnych dodatkowych ról. Wybrałem „Wszystkie” porty TCP i UDP dla powiązań / połączeń. Nie dodałem booleanów do polityki. Po uruchomieniu wygenerowanego .sh utworzono nowego użytkownika i rolę SELinux. Następnie przypisałem nazwę logowania „ograniczonemu użytkownikowi”. Zgodnie z oczekiwaniami dało mi to użytkownika z bardzo ograniczonymi uprawnieniami.

(3) Początkowo ten nowy użytkownik mógł utworzyć skrypt w swoim katalogu domowym, ale nie mógł go wykonać. Po ustawieniu wartości logicznej o nazwie „allow_guest_exec_content” użytkownik był w stanie wykonać skrypt. Początkowo skrypt zawierał tylko „echo”, ale gdy zmieniłem go, aby wysłać polecenie ping, nie powiodło się. Próbując zezwolić na ping dla tego nowego użytkownika, odznaczyłem wartość logiczną user_ping (chociaż myślę, że dotyczy to tylko user_u, a nie guest_u). Aby zrobić to, co chcę, myślę, że alternatywą może być zdefiniowanie typu opartego na „user_u”, a następnie usunięcie uprawnień (zamiast podejścia, które podjąłem, czyli pójścia z typem opartym na guest_u i dodawanie uprawnień - jednak nie też nie wiem jak to zrobić!).

(4) Wiele źródeł online omawia pliki zasad z katalogu src, ale nie został on zainstalowany i nie mogłem dowiedzieć się, który pakiet do zainstalowania mógłby to dodać. Mam zainstalowane następujące pakiety związane z selinux:

libselinux.x86_64                   2.0.94-5.3.el6                     installed
libselinux-devel.x86_64             2.0.94-5.3.el6                     installed
libselinux-python.x86_64            2.0.94-5.3.el6                     installed
libselinux-utils.x86_64             2.0.94-5.3.el6                     installed
selinux-policy.noarch               3.7.19-126.el6_2.4                 @updates 
selinux-policy-targeted.noarch      3.7.19-126.el6_2.4                 @updates 
setools-console.x86_64              3.3.7-4.el6                        @base    
setools-devel.x86_64                3.3.7-4.el6                        @base    
setools-gui.x86_64                  3.3.7-4.el6                        @base    
setools-libs.x86_64                 3.3.7-4.el6                        @base    
setools-libs-java.x86_64            3.3.7-4.el6                        @base    
setools-libs-python.x86_64          3.3.7-4.el6                        @base    
setools-libs-tcl.x86_64             3.3.7-4.el6                        @base 

(5) Spojrzałem na alternatywną ograniczoną powłokę, taką jak http://lshell.ghantoos.org/, ale moja firma wymaga albo użycia SELinuksa, albo - jeśli wszystko nie korzysta z czegoś już dostarczonego przez system operacyjny (np. Bash ograniczony) ale może to nie być tak bezpieczne.

Myślę, że muszę zdefiniować niestandardową politykę, w ramach której:

(a) Pozwól użytkownikowi na wykonywanie plików w swoim katalogu domowym.

(b) Pozwól skryptom użytkownika przejść na różne typy w celu uruchomienia poleceń, do których użytkownik nie ma uprawnień.

Używając graficznego interfejsu użytkownika SELinux (i plików konfiguracyjnych, o których wiem) nie mam pojęcia, jak to zrobić.

Dzięki za wszelką pomoc, którą możesz udzielić.

Stuart
źródło

Odpowiedzi:

0

Z wersji pakietów, którą jest CentOS 6. Podejście do tego problemu, który obecnie wdrażam, którego głównymi zaletami są możliwości inspekcji (poprzez sudo), prostota (niewymagająca MLS / MCS) i ograniczenie, są następujące:

  • Użytkownicy otrzymują HOMEkatalog za pomocąpam_namespace
  • Użytkownicy otrzymują rbashpowłokę logowania
  • HOME jest zamontowany noexec,ro, a rzeczy takie jak HISTFILEwskazywanie poza domem na kontrolowane miejsce w innym miejscu
  • Użytkownicy są mapowani do user_useuser
  • Użytkownicy mają swój PATHzestaw tylko do odczytu ~/bin, gdzie istnieją dowiązania symboliczne do dozwolonych (podstawowych) plików binarnych
  • Użycie sudojest obowiązkowe dla każdego innego polecenia, którego nie ma w~/bin
  • /etc/sudoersplik zawiera reguły, które uwzględniają rolę i wymuszanie typu docelowego użytkownika / polecenia za pomocą opcji SELinux_Specokreślania opcji rolei typesudoers.

Ten post na blogu opisuje przypadek użycia. Wątek ten odnosi się do stanu rzeczy w odniesieniu do RHEL5 / CentOS5 i RHEL6 / CentOS6

dawud
źródło