W większości przypadków podczas instalowania programu ze źródła zaleca się utworzenie nowego użytkownika i nowej grupy oraz nadanie /usr/local/<myapp>nowo utworzonemu użytkownikowi i grupie praw własności.
Dlaczego taka praktyka jest uważana za dobrą praktykę?
Co to poprawia?
Przykład: użytkownik mysql / grupa mysql dla serwera bazy danych MySQL.
Odpowiedzi:
Praktyką nie jest tworzenie jednego użytkownika i grupy na aplikację, ale na usługę. Oznacza to, że programy wykonywane przez lokalnego użytkownika nie muszą być instalowane jako użytkownik inny niż root. Są to demony , programy działające w tle i wykonujące żądania przychodzące przez sieć lub inne środki komunikacji, które powinny działać jako dedykowany użytkownik.
Demon działa jako oddany użytkownik, więc jeśli źle zachowuje się (z powodu błędu, prawdopodobnie wywołanego przez atakującego), szkody, które może wyrządzić, są ograniczone: dotyczy to tylko plików danych demona (chyba że atakującemu udało się znaleźć lokalną główną dziurę , co może się zdarzyć). Na przykład demon bazy danych mysqlddziała jako dedykowany użytkownik i grupa, mysql:mysqla pliki danych bazy danych ( /var/lib/mysql/*) należą mysql:mysql.
Należy pamiętać, że plik wykonywalny demona i inne dane statyczne i pliki konfiguracyjne, które są używane, ale nie powinny być modyfikowane przez demona, nie mogą należeć do dedykowanego użytkownika; powinny być własnością root:root, podobnie jak większość programów i plików konfiguracyjnych. W mysqldprocesie nie ma nadpisywania biznesowego /usr/sbin/mysqldlub /etc/mysql/my.cnfdlatego te pliki nie mogą należeć do mysqlużytkownika ani być zapisywalne przez mysqlużytkownika lub mysqlgrupę. Jeśli niektóre pliki muszą być odczytywalne tylko przez demona i administratora, powinny być własnością użytkownika root i dedykowanej grupy oraz mieć tryb 0640 ( rw-r-----).
Specjalną kategorią plików wykonywalnych, których właścicielem nie może być, root:rootsą programy wywoływane przez użytkownika, ale wymagające uruchamiania z dodatkowymi uprawnieniami. Te pliki wykonywalne muszą być setuid root, jeśli muszą działać (przynajmniej częściowo) jako root; wówczas plik wykonywalny musi mieć tryb 4755 ( rwsr-xr-x). Jeśli program potrzebuje dodatkowych uprawnień, ale nie ma uprawnień roota, należy ustawić go na setgid, aby dodatkowe uprawnienia były przekazywane przez grupę, a nie przez użytkownika. Plik wykonywalny ma wtedy tryb 2755 ( rwxr-sr-x). Powody są dwojakie:
Powodem, dla którego uważa się to za dobrą praktykę, jest uniemożliwienie innym użytkownikom systemu przesłonięcia danych i plików konfiguracyjnych dla określonej aplikacji.
Jako przykład mysql/ mysqlbędąc właścicielem magazynu plików bazy danych mysql, nikt nie używa interfejsu API aplikacji przed uszkodzeniem baz danych. Ponadto użytkownik mysqlzwykle nie ma prawdziwej powłoki, więc nikt nie może się zalogować jako ten użytkownik.
/usr/bin/atjest własnością daemon/daemonUbuntu
atnie jest demonem. Jest setuid, daemonaby mógł komunikować się z atddemonem za pomocą prywatnych plików.
Utworzenie nowej grupy / użytkownika dla nowego zainstalowanego demona poprawia bezpieczeństwo. Gdy proces serwera jest uruchamiany przez takiego użytkownika, jest on ograniczony do praw dostępu tego użytkownika. Dla porównania: gdy jest uruchamiany jako root, może zrobić wszystko.
Ta różnica jest ważna w przypadku, gdy demon jest źle skonfigurowany i / lub zawiera błąd związany z bezpieczeństwem.
Nie jestem pewien, co masz na myśli przez drugą część twojego pytania, tj. Część dotyczącą /usr/localwłasności. Zasadniczo nie ma sensu, aby ten sam użytkownik, Xpod którym demon działał ze względów bezpieczeństwa, jest również właścicielem katalogu z plikami binarnymi (ponieważ w takim przypadku mógłby je zmienić w przypadku exploita). Ale katalog z plikami danych, na których działa demon, powinien być dostępny X- najłatwiejszym sposobem skonfigurowania tego jest uczynienie Xwłaściciela katalogów / plików danych.
Uruchamianie demona przez własnego specjalnego użytkownika to tylko jedna technika bezpieczeństwa, inne obejmują „chrootowanie” lub używanie systemu obowiązkowej kontroli dostępu (MAC) (np. SELinux).
Jest to kwestia bezpieczeństwa. Ogranicza szkody, które może wyrządzić ktoś włamujący się do aplikacji demona. Aplikacje użytkownika są zazwyczaj własnością standardowego identyfikatora użytkownika, takiego jak root.
Jeśli Twój serwer WWW, serwer poczty i baza danych działają jako ten sam użytkownik, łatwiej jest ich złamać. Jeśli którakolwiek z nich zawiera błąd lub nieprawidłową konfigurację, która umożliwia dostęp do systemu, dostęp ten można wykorzystać do uzyskania dostępu do wszystkich trzech aplikacji.
Jeśli wszystkie mają osobne konta, zgodnie z zaleceniami, prawdopodobnie tylko zaatakowana aplikacja będzie dostępna. Chociaż można odczytać szczegóły konfiguracji publicznej tego drugiego, jest mało prawdopodobne, aby można było wprowadzić zmiany.
Wiele demonów pozwala użytkownikom przesyłać i pobierać pliki oraz w inny sposób robić rzeczy, których nie chciałbyś, aby mogli robić z konfiguracjami dla innych demonów. Jeśli każda aplikacja ma własny identyfikator użytkownika i grupę, łatwiej jest zabezpieczyć demony.
Posiadanie grupy specyficznej dla demona ułatwia bezpieczne udzielanie demonowi bezpiecznego dostępu tylko do odczytu do plików i katalogów. Jeśli plik lub katalog jest własnością innego użytkownika, ale należy do grupy demonów, zwykle będzie dostępny tylko do odczytu. Uprawnienia dostępu można łatwo zweryfikować i poprawić za pomocą narzędzi takich jak find.