2015-06-17 24 views
5

Znalazłem tę odpowiedź na learning Linux Kernel Programming, a moje pytanie jest bardziej specyficzne dla funkcji bezpieczeństwa jądra systemu Linux. Chcę wiedzieć, jak ograniczyć uprzywilejowanych użytkowników lub prawa dostępu do procesu do innych procesów i plików, w przeciwieństwie do pełnego dostępu root.Jak ograniczyć dostęp dla uprzywilejowanych użytkowników na poziomie jądra Linux?

Do tej pory znalazłem:

  • użytkownikowi i grupę dla uznaniowe kontroli dostępu (DAC), ze zróżnicowania odczytu, zapisu i wykonania dla użytkownika, grupy i innych korzeni
  • użytkownika na wyższe uprzywilejowanych zadań
  • setuid i setgid przedłużyć d użytkowników męska AC i ustaw identyfikator grupy/użytkownika procesu wywołującego, np. użytkownik uruchamia ping z uprawnieniami roota do otwierania gniazd Linuksowych
  • Możliwości dla uprawnień szczegółowych, np. usunięcie bitu suid z ping i ustawić cap_net_raw
  • grupie kontrolnej (Cgroups) ograniczenie dostępu do zasobów, czyli procesora, sieci, IO urządzenia
  • przestrzeni nazw do widoku oddzielnym procesie w sprawie IPC, sieci, plików, PID
  • Secure Computing (seccomp) do systemu ograniczania połączeń
  • Linux Security Modules (LSM), aby dodać dodatkowe funkcje zabezpieczeń, jak Access Control obowiązkowe, np SELinux z egzekwowaniem typu

Czy lista jest kompletna? Podczas pisania pytania znalazłem fanotify do monitorowania zdarzeń systemu plików, np. do skanowania antywirusowego. Prawdopodobnie jest więcej dostępnych funkcji bezpieczeństwa.

Czy istnieje więcej funkcji zabezpieczających systemu Linux, które mogą być używane jako w programowalny sposób z wewnątrz lub z zewnątrz pliku lub procesu w celu ograniczenia dostępu uprzywilejowanego? Być może jest pełna lista.

+2

Przeczytaj [referencje (7)] (http://man7.org/linux/man-pages/man7/credentials.7.html) i [możliwości (7)] (http://man7.org/linux /man-pages/man7/capabilities.7.html) i [namespaces (7)] (http://man7.org/linux/man-pages/man7/namespaces.7.html) & [xattr (7)] (http://man7.org/linux/man-pages/man7/xattr.7.html) –

Odpowiedz

2

tradycyjny sposób Unix ograniczyć proces, który w jakiś sposób potrzebuje więcej przywilejów, a jednocześnie zawiera je tak, aby nie mógł używać więcej niż to, czego potrzebuje, aby je "chrootować".

chroot zmienia pozorny katalog główny procesu. Jeśli zostanie to zrobione poprawnie, może uzyskać dostęp tylko do tych zasobów wewnątrz nowo utworzonego środowiska chroot (np. Chroot jail) np. może tylko uzyskać dostęp do tych plików, ale także tylko te urządzenia itp.

Aby utworzyć proces, który robi to chętnie, jest stosunkowo łatwy, a nie taki rzadki.

Aby utworzyć środowisko, w którym istniejące oprogramowanie (np. Serwer WWW, serwer pocztowy, ...) czuje się w domu i nadal działa prawidłowo, to coś, co wymaga doświadczenia. Najważniejsze jest znalezienie minimalnego zestawu potrzebnych zasobów (biblioteki współdzielone, pliki konfiguracyjne, urządzenia, usługi zależne (np. Syslog), ...).

+0

Witam, środowisko chroot nie ogranicza dostępu do jądra. Jeśli proces wewnątrz chroota wymaga dostępu uprzywilejowanego, to jest do otwierania portów uprzywilejowanych <1024 (w twoim przykładzie dotyczy to serwera WWW), więc chroot będzie działał z uprawnieniami roota, co pomaga wyjść z więzienia. Zobacz http://unixwiz.net/techtips/chroot-practices.html – andpei

+0

w przypadku serwera WWW: uruchom go w chroot na innym porcie, jeśli jest to potrzebne, aw najgorszym wypadku możesz użyć filtra pakietów lub zapory do przekierowania portów 80 i 443 do niego. Ale zgadzam się, że to nie ogranicza dostępu do jądra. Jeśli jednak program jest do tego napisany, może pozostawić większość, jeśli nie wszystkie, plików poza środowiskiem chroot, następnie upuścić uprawnienia, a następnie wykonać samą procedurę chroot. W ten sposób masz tylko zwykłe uprawnienia użytkownika i np. brak zbędnych urządzeń, plików binarnych, bibliotek itp. wewnątrz środowiska chroot. – swa66

-1

Możesz dodać EFS, AppArmor, Yama auditctl, ausearch, aureport Narzędzia podobne do fanotify: Snort, ClamAV, OpenSSL, adiutant, nmap, GnuPG

+0

Witam, moje pytanie dotyczy ograniczenia prywatności. dostęp do użytkownika w jądrze, ale nie szyfrowanie (EFS, OpenSSL, GnuPG) lub wykrywanie włamań i bezpieczeństwo sieci (AIDE, Snort, nmap). AppArmor i Yama są również dostarczane przez LSM. audititu, ausearch, aureport są również używane przez SELinux. – andpei