Dlaczego system ma /etc/sudoers.d? Jak powinienem to edytować?

Ostatnim razem zapytałem o ryzyko tych (w / etc / sudoers):

    user_name ALL=(ALL) /usr/bin/vim /etc/httpd/confs/httpd.conf
    %group_name ALL=(ALL) /usr/bin/vim /etc/httpd/confs/httpd.conf

Podczas gdy myślałem o tym problemie, znalazłem katalog /etc/sudoers.d . Pliki w katalogu powinny mieć podobne funkcje do / etc / sudoers (co oznacza, że ​​powyższe skrypty są nadal problematyczne, nawet w /etc/sudoers.d), a jednak w jednym artykule stwierdzono, że nie powinniśmy używać katalogu, ponieważ nie możemy używać visudodo edycji plików w to. Oznacza to, że tracimy prawo do używania, sudojeśli popełnimy błąd w katalogu.

Jeśli to prawda, dlaczego mamy /etc/sudoers.d ? Czy mamy dobry sposób na edycję plików w /etc/sudoers.d ?

Zmiany wprowadzone w plikach /etc/sudoers.dpozostaną na miejscu po uaktualnieniu systemu. Może to zapobiec blokowaniu użytkownika podczas aktualizacji systemu. Ubuntu lubi to zachowanie. Inne dystrybucje również używają tego układu.

Z mojego doświadczenia wynika, że ​​zasady dotyczące plików w tym katalogu są luźniejsze niż w przypadku /etc/sudoers. Obejmuje to:

• Błędy w pliku nie spowodowały sudoniepowodzenia. Plik został jednak zignorowany.
• Zasady wydawania uprawnień wydają się mniej surowe. Umożliwia odpowiedniej grupie lub innej osobie odczytanie pliku. Nie sądzę, żeby było to możliwe /etc/sudoers. Aby rootzachować bezpieczeństwo, należy ograniczyć uprawnienia do zapisu . Obecna wersja sudo Ubuntu pozwala na uprawnienia do odczytu dla grupy lub innej. (Ta funkcja umożliwia kontrolę dostępu sudo za pomocą bez konieczności dostępu do konta root.)

visudoKomenda tylko domyślnie /etc/sudoers. Będzie edytować i weryfikować dowolny plik określony za pomocą -fopcji. Korzystam z tej możliwości, aby edytować pliki, które zostaną automatycznie zainstalowane jako /etc/sudoerslub w /etc/sudoders.d. Jednak definicje z innych plików mogą nie zostać znalezione. Najlepiej jest uniezależnić plik.

Możliwość posiadania plików autonomicznych ułatwia aplikacji włączenie sudofunkcji instalacji i usunięcie ich po odinstalowaniu. Zautomatyzowane narzędzia konfiguracyjne mogą również korzystać z tej możliwości.

Wykorzystałem tę możliwość do wyodrębnienia zmian wymaganych do przyznania dostępu do określonych grup użytkowników w określonych systemach.

Tak, możesz użyć visudodo edycji tych plików. Wszystko, co musisz zrobić, to podać nazwę pliku, który chcesz edytować za pomocą -fopcji. Na przykład:

visudo -f /etc/sudoers.d/somefilename

Lub w razie potrzeby:

sudo visudo -f /etc/sudoers.d/somefilename

Dokumentacja

Od man visudo:

-f sudoers
Określ i alternatywną lokalizację pliku sudoers. Dzięki tej opcji visudo będzie edytować (lub zaznaczać) wybrany plik sudoers, zamiast domyślnego pliku / etc / sudoers. Używany plik blokady to określony plik sudoers z dołączonym „.tmp”. Tylko w trybie tylko do sprawdzenia argumentem -f może być „-”, co oznacza, że ​​sudoery będą czytane ze standardowego wejścia.

W podsumowaniu:

1. Składnia: oba visudoi visudo -f wykonaj to samo sprawdzenie składni .

2. Uprawnienia / Własność: Jako funkcja dodana w celu ułatwienia administrowania dużymi systemami , edytowane pliki visudo -fnie są sprawdzane pod kątem własności lub uprawnień: umożliwia to sprawdzenie składni pliku offline lub jako część systemu kontroli wersji.

Dlaczego warto korzystać /etc/sudoers.d/

Zazwyczaj /etc/sudoersjest pod kontrolą menedżera pakietów dystrybucji. Jeśli dokonałeś zmian w tym pliku, a menedżer pakietów chce go zaktualizować, będziesz musiał ręcznie sprawdzić zmiany i zatwierdzić sposób ich połączenia z nową wersją. Umieszczając lokalne zmiany w pliku w /etc/sudoers.d/katalogu, unikasz tego kroku ręcznego, a aktualizacje mogą przebiegać automatycznie.

Kiedy sudoignoruje plik /etc/sudoers?

Jeśli twój /etc/sudoersplik zawiera wiersz:

#includedir /etc/sudoers.d

następnie sudoodczyta pliki z katalogu /etc/sudoers.d.

Wyjątkami są:

1. Pliki, których nazwy kończą się na ~
2. Pliki, których nazwy zawierają .znak

Odbywa się to (a) dla wygody menedżerów pakietów, a także (b), aby pliki kopii zapasowych z edytorów były ignorowane.

dlaczego mamy /etc/sudoers.d?

Ponieważ łatwiej jest zautomatyzowanym narzędziom (takim jak Chef czy Puppet) upuszczać pojedyncze pliki do tego katalogu, zamiast wprowadzać zmiany /etc/sudoers, które mogą być kruche.

Pliki w /etc/sudoers.dsą (faktycznie) łączone. Zobaczysz kilka innych przykładów tego wzoru /etc, takich jak /etc/cron.di /etc/logrotate.d.

Inną zaletą używania, visudo -fjak wspomniano w niektórych odpowiedziach, jest odpowiednia opcja -club --checkweryfikacja, czy nie masz nieprawidłowych informacji w pliku sudoers.d lub innym pliku, który możesz chcieć umieścić w sudoers.d. Jest to NAPRAWDĘ przydatne w wymienionych przypadkach zautomatyzowanych narzędzi, ponieważ można uruchomić np

sudo visudo -c -q -f /home/myuser/mysudoers && \
sudo chmod 600 /home/myuser/mysudoers && \
sudo cp /home/myuser/mysudoers /etc/sudoers.d/mysudoers

To po cichu sprawdza plik (brak danych wyjściowych z powodu -q) i tylko jeśli to NIE zwróci błędu (wyjście 1 oznacza nieprawidłowy plik sudoers), wówczas skopiuje plik do sudoers.d, w ten sposób możesz utworzyć plik i pracuj nad nim bez konieczności sudo visudo -f /etc/sudoers.d/myfilepoprawiania go za pierwszym razem (używanie musi zakończyć się powodzeniem lub odrzuca zawartość, jeśli jej nie naprawisz).

Ponadto należy zachować ostrożność w odniesieniu do tych stwierdzeń z innych odpowiedzi.

Z mojego doświadczenia wynika, że ​​reguły dotyczące plików w tym katalogu są luźniejsze niż w przypadku / etc / sudoers. Obejmuje to:

Błędy w pliku nie spowodowały niepowodzenia sudo. Plik został jednak zignorowany. Zasady wydawania uprawnień wydają się mniej surowe. Pozwalam odpowiedniej grupie odczytać plik. Nie wierzę, że jest to możliwe w przypadku / etc / sudo.

Pliki w /etc/sudoers.d muszą być zgodne z tą samą składnią, co / etc / sudoers, ponieważ pod okładkami system po prostu łączy wszystkie pliki z ostatnim w „wygrywającym”, jeśli jest wiele wpisów dla tego samego pojedyncze ustawienie.

Jeśli uprawnienia są strasznie niepoprawne (zapisywalne na całym świecie) dla plików w /etc/sudoers.d/, wówczas są one ignorowane, może to powodować, że nieprawidłowe pliki są pomijane, w przeciwnym razie możesz poważnie złamać sudopolecenie, mając nieprawidłowe sudoers. d plik z prawidłowymi uprawnieniami.

Możesz zezwolić plikom sudoers na odczytanie na całym świecie, jeśli przypadkowo zezwolisz „innemu” na uprawnienie do zapisu potrzebne do sudo jako inny użytkownik lub z terminala głównego uruchom tę komendę. Może to również spowodować uszkodzenie, jeśli plik należy do kogoś innego niż root: root.

sudo chmod 644 /etc/sudoers.d/mysudoers
sudo chown root:root /etc/sudoers.d/mysudoers

Właśnie potwierdziłem, że jeśli uruchomię, nie chmod o+w /etc/sudoers.d/vagrantbędę mógł dłużej sudo jako włóczęgi, wyświetli monit o podanie hasła, a następnie się nie powiedzie.

Kiedy pobiegłem, sudo -laby wyświetlić zastosowane uprawnienia polecenia jako inny prawidłowy użytkownik sudo, otrzymałem również ostrzeżenie o uprawnieniach do plików. To jest to samo polecenie, którego użyłem, aby potwierdzić, że użytkownik „włóczęga” stracił sudo, kiedy zastosowałem o+wuprawnienia do pliku, nadając mu uprawnienia sudo.

Tylko krótki dodatek do dowolnej ogólnej odpowiedzi ... żadna z pozostałych odpowiedzi nie rozwiązała mojego problemu, a mianowicie, że kolejność ma znaczenie.

Jeśli twoje linie działają w sudoers, ale nie sudoers.d, spróbuj przesunąć #include lub zmienić kolejność plików sudoers.d (przez prefiks z liczbą). Wydaje się, że najbardziej konkretna rzecz powinna być pierwsza w pliku.

Miałem coś takiego:

somebody ALL=(ALL): somecommand
somebody ALL=(someoneelse) NOPASSWD: somecommand

A drugi nie przyniósł efektu, ponieważ pierwszy już pasował. NOPASSWD nie jest warunkiem, ale jakimś sposobem modyfikacji akcji.

I nie było to oczywiste, ponieważ nie było go w jednym pliku ze względu na katalog sudoers.d.