Czy „sudo su -” jest uważane za złą praktykę?

tło

Znam różnicę między su -, sudo su -oraz sudo <command>:

• su - - przełącza użytkownika na root, wymaga hasła roota
• sudo su - - przełącza użytkownika na root, wymaga tylko hasła bieżącego użytkownika
• sudo <command>- przyznaje dostęp do konta root tylko dla określonego polecenia; wymaga tylko hasła bieżącego użytkownika

Moje pytanie dotyczy tego, czy używanie sudo su -jest bezpieczną praktyką w środowisku produkcyjnym.

Kilka myśli:

1. Wydaje się, że zezwalanie sudo su -stanowi zagrożenie dla bezpieczeństwa, uzależniając dostęp do konta root od haseł poszczególnych użytkowników. Oczywiście można to złagodzić, egzekwując ścisłą politykę haseł. Nie wydaje mi się, żeby su -było lepiej, ponieważ wymagałoby od administratora dzielenia faktycznego hasła roota.

2. Zezwolenie użytkownikom na całkowite przełączenie się na konto root utrudnia śledzenie, kto wprowadza zmiany w systemie. W mojej codziennej pracy widziałem przypadki, w których wielu użytkowników ma sudo su -dostęp. Pierwszą rzeczą, którą robią użytkownicy, logując się do systemu, jest uruchamiana sudo su -przed rozpoczęciem pracy. Pewnego dnia coś się psuje i nie ma możliwości śledzenia, kto był uruchomiony rm -rf *w niewłaściwym katalogu.

pytania

Biorąc pod uwagę powyższe obawy, czy dobrym pomysłem jest zezwolenie użytkownikom na korzystanie, sudo su -czy su -w ogóle?

Czy istnieją jakieś powody, dla których administrator skonfigurowałby konta użytkowników dla ( sudo su -lub su -zamiast sudo <command>lenistwa)?

Uwaga: ignoruję przypadek, w którym użytkownik działający sudo su -lub su -Administrator musi wprowadzić zmiany systemowe, gdy bezpośredni dostęp ssh został wyłączony dla użytkownika root.

Spójrzmy na twoje skrzynki:

 su -

uruchomi / bin / sh jako użytkownik root korzystający ze środowiska root. Hasło roota jest potrzebne, a logowanie MOŻE być rejestrowane w zależności od ustawień syslog (zwykle domyślnie jest to /var/log/auth.log).

 sudo /bin/sh

uruchomi powłokę jako użytkownik root przy użyciu bieżącego zestawu zmiennych środowiskowych (z pewnymi wyjątkami, które zostałyby zdefiniowane w pliku sudoers). Hasło to hasło użytkownika źródłowego, a NIE hasło użytkownika root. sudo jest zwykle logowane.

 sudo su -

uruchomi powłokę (zwykle / bin / sh) jako użytkownik root konfigurujący środowisko jako użytkownik root. Będzie to wymagało hasła użytkownika źródłowego i na ogół będzie rejestrowane.

Czasami konieczne jest posiadanie środowiska root nad własnym środowiskiem, dlatego su - jest odpowiednią metodą. Pamiętaj, że w obu przypadkach sudo będzie nadal rejestrować użycie polecenia powłoki.

* Biorąc pod uwagę powyższe obawy, czy dobrym pomysłem jest zezwolenie użytkownikom na używanie sudo su *

Nie, nie moim zdaniem. Nie ma praktycznej przewagi nad umożliwieniem im su, chyba że nie potrzebują do tego hasła root.

czy su - w ogóle?

Ponieważ zawsze wyłączam logowanie roota, su jest konieczne i w równowadze, czyni serwer bezpieczniejszym.

Wydaje się, że OP zapewnia wiele dobrych powodów, aby nie zezwalać / zachęcać do ogólnych zastosowań do uruchomienia sudo bashlub sudo su -od tego przełącza je do wszechmocnego trybu, którego elementy wewnętrzne na ogół nie są rejestrowane. I mogą zapomnieć, że są w tym trybie i zrobić coś ... godnego pożałowania.

Ergo, wydaje się bezpieczniejsze, że większość użytkowników ogranicza się do uruchamiania sudo on/a/particular/command/lub listy poleceń. W ten sposób rejestrowane jest każde polecenie sudo.

Czy spotkasz się z wyjątkami w praktyce? Pewnie. Czy reakcja na takie wyjątki powraca do leniwej praktyki nieograniczonej - sudo suprawdopodobnie nie.