Linux: ze względów bezpieczeństwa zamknięcie nie może zostać wykonane

Dzisiaj przez pomyłkę zamknąłem maszynę produkcyjną, ponieważ myślałem, że jestem na mojej lokalnej maszynie. Wiem, błąd początkującego :-(

Jako rozwiązanie, które nie miało się powtórzyć, myślałem o usunięciu uprawnienia do wykonania polecenia zamknięcia, ponieważ ta maszyna powinna być zawsze włączona.

Czy to dobry pomysł? Czy robiąc to, widzisz niepożądany efekt uboczny?

Pozdrawiam, Dan

Zupełnie innym podejściem do ostrzeżenia, że ​​pracujesz na maszynie produkcyjnej, jest oznaczenie terminala. Na przykład user@machine:~#tekst może być czerwony na maszynach produkcyjnych, zielony na etapie rozwoju itp. Oto fajny samouczek, jak to zrobić: Podpowiedź Color Bash

Najlepsza rada, jaką mogę ci dać, to nie logować się jako root, chyba że potrzebujesz dostępu do roota i upewnij się, że masz inne hasło root / sudo na każdym komputerze.

Niedostępność wyłączenia jest jedną z opcji, ale nie jest dobra. Albo alias shutdowndo shutdown -ai touch /etc/shutdown.allowlubchmod a-x /sbin/shutdown

Gdzie to się kończy? Czy zamierzasz także zabronić zatrzymywania, restartowania i inicjowania?

Kilka punktów do rozważenia:

1. Co robiłeś jako root w systemie produkcyjnym w czasie produkcji? Skonfiguruj swoje systemy, abyś nie musiał być na nich zrootowany do codziennej pracy. Nigdy nie powinieneś rootować w systemie produkcyjnym bez bardzo dobrego powodu.
2. Naucz się ważnej lekcji. Kiedy jesteś rootem, musisz dwukrotnie sprawdzić przed naciśnięciem enter. SUDO nie stanowi ochrony, jeśli po prostu napiszesz hasło, aby kontynuować, bez zastanowienia. Szybka kolorystyka, o której wspomniał mkudlacek, jest bardzo przydatnym narzędziem, które pomaga upewnić się, że nie masz złego systemu.
3. Nie zadzieraj z wbudowanymi narzędziami. Prawdopodobnie zepsuje aktualizacje i doprowadzi nowych pracowników do szaleństwa. Jeśli chcesz coś zmienić, użyj własnego pliku aliasu.

Nie sądzę, że bałagan z włączonymi uprawnieniami shutdownjest sposobem na poradzenie sobie z sytuacją. Zasadniczo właśnie nauczyłeś się lekcji. Podbródek.

Robiłem te same rzeczy - robiłem długie łańcuchy sesji ssh, a potem bawiłem się trasami na jednej z maszyn, przez które byłem ssh, odcinając się. Spartaczyłem żądanie rsync, co doprowadziło do systematycznego niszczenia systemu po drugiej stronie świata. Uruchomiłem rm -rf / pathna serwerze produkcyjnym. (Tym razem dowiedziałem się, jak działały przywracania.)

Tak więc, dużo starszy i mam nadzieję, że trochę mądrzejszy, teraz mam surowe zasady, które sobie narzucam.

• Wszystkie monity roota kończą się na #, bez względu na to, jakie są w nich inne informacje.
• Za każdym razem, gdy pojawia się monit #, dosłownie siadam na rękach przed naciśnięciem klawisza Enter.
• Jeśli są jakieś wątpliwości co do tego, co zamierzam zrobić lub gdzie naprawdę jestem, lub jak się tam dostałem, anuluję je i odbuduję ponownie ze znanego stanu początkowego.
• Kiedy popełniam błąd (i wciąż go popełniam, chociaż z czasem stają się one coraz rzadsze i coraz bardziej niejasne), natychmiast dowiedz się, co zrobiłem, na kogo wpłynąłem, i powiedz im swoje grzechy . Następnie zrzuć wszystko inne i cofnij damange tak szybko i najlepiej jak potrafisz.

Charakter mojej pracy wymaga ode mnie spędzania dużo czasu na wielu różnych podpowiedziach dotyczących rootowania, ale dzięki moim błędom z przeszłości utrzymuję znacznie lepszą świadomość sytuacyjną niż na początku.

Jeśli używasz Ubuntu, wypróbuj Molly-guard. Jak omówiono w tym podobnym pytaniu .

Zależy, naprawdę. Możesz spróbować po prostu zawinąć polecenie, ale oznacza to, że jeśli wykonasz aktualizacje lub uaktualnienia, które wpływają na ten plik wykonywalny, możesz o nim zapomnieć i popsuć aktualizację. Gra za pomocą komend zamykania systemu może być PITA, szczególnie jeśli masz nowych pracowników lub zastępcę, który nie wie, że grasz z binariami systemowymi.

Osobiście chciałbym spojrzeć na zawijanie polecenia w skrypcie, który identyfikuje system według nazwy i sprawia, że ​​naprawdę chcesz to zrobić przed uruchomieniem rzeczywistego pliku binarnego lub że musisz wpisać określoną sekwencję liter, aby potwierdzić zamknięcie zanim uruchomi binarny. To powinno dać chwilę przerwy.

Możesz rozważyć ustawienie wiersza polecenia tak, aby zawierał nazwę komputera, przynajmniej na serwerach. Pomoże to w przyszłości zapobiec uruchamianiu innych poleceń na niewłaściwym komputerze. Bardziej efektywne jest, jeśli nazwy komputerów są pokolorowane, aby się wyróżniały, a nawet można kodować kolory w celu zidentyfikowania ról serwera.

Jednym ze sposobów jest nieużywanie sui / lub logowanie się bezpośrednio do root. Lepiej zalogować się bezpośrednio na konto ORAZ mieć inne hasło do rootkomputera lokalnego i klucza SSH.

Oczywiście jest to dodatek do oglądania czerwonego znaku zachęty „#”.

Tak, usunięcie bitu wykonania z polecenia shutdown jest najprostszym i najbezpieczniejszym sposobem zapobiegania przypadkowym wyłączeniom, szczególnie jeśli masz na komputerze środowisko takie jak KDE i chcesz zapobiec przypadkowym wyłączeniom podczas wylogowywania.

Jeśli chodzi o zamieszanie nowych osób, myślę, że pierwszą rzeczą, jaką zrobią, będzie ls -l /sbin/shutdownustalenie, dlaczego to nie działa (zwłaszcza jeśli mają dobry nawyk uzupełniania nazw plików wykonywalnych). Oczywiście powinieneś powiedzieć im o wszelkich dokonanych zmianach.

Dla dodatkowego bezpieczeństwa możesz dodać wiersz, aby /etc/rc.localusunąć bit wykonawczy z polecenia shutdown, więc nie zapomnij zresetować go po ponownym uruchomieniu.

możesz po prostu usunąć / sbin / ze ścieżki roota. w ten sposób musisz wpisać pełną ścieżkę, aby ją wykonać, i zwykle naprawia wypadki.