Udzielanie dostępu do zestawu poleceń użytkownikowi innemu niż root bez sudo

Chcę przyznać dostęp inny niż sudo użytkownikowi innemu niż root na moim komputerze, istnieje użytkownik dns-manager, jego jedyną rolą jest uruchamianie wszystkich poleceń BIND (rndc, dnssec-keygen) itp.

Teraz za każdym razem, gdy musi wykonać polecenie, pisze:

sudo rndc reload

Czy istnieje sposób na pozbycie się tego sudo, ale tylko na określonym zestawie poleceń (i tylko dla dns-manager)?

Jeśli dobrze rozumiem twoje komentarze, problem polega na tym, że polecenie zostanie wydane przez połączenie, które nie ma możliwości wprowadzenia hasła, którego domyślnie wymaga sudo. Ponadto w wielu dystrybucjach systemu operacyjnego sudo będzie domyślnie wymagało TTY - czego ten program może nie mieć.

Jednak sudo może mieć bardzo szczegółową strukturę uprawnień, dzięki czemu jeden lub więcej użytkowników może wydać jedno polecenie bez hasła i TTY. Poniżej przedstawię trzy sposoby skonfigurowania tego do własnych potrzeb. Niezależnie od tego, który wybierzesz, użytkownik będzie mógł wydać polecenie sudo rndc reloadbez konieczności wprowadzania hasła.

(Również, może to być konieczne, ale ... proszę pamiętać, aby zrobić kopię zapasową pliku sudoers przed jego edycję, aby utrzymać skorupę gdzie jesteś otwarty główny w przypadku trzeba przywrócić do kopii zapasowej, a do edycji używając go visudozamiast sudo vi /etc/sudoers. Mam nadzieję, że te środki ostrożności będą niepotrzebne, ale ... lepiej je mieć i nie potrzebować ich niż na odwrót!)

1. Jeśli nie chcesz wymagać TTY dla jakichkolwiek żądań

Najłatwiejszym sposobem na pozbycie się wymagań TTY (jeśli taki istnieje) jest upewnienie się, że wiersz zaczynający się na Defaultsin /etc/sudoersnie zawiera słowa requiretty- zamiast tego powinien zawierać !requiretty. Jednak jeśli to zrobisz, oznacza to, że żadne polecenie sudo nie będzie wymagać tty!

Będziesz także musiał dodać linię

rndcuser ALL = (root) NOPASSWD: /path/to/rndc reload, /path/to/dnssec-keygen, /path/to/other/program

2. Jeśli chcesz wymagać TTY dla wszystkich użytkowników oprócz tego

Można to zrobić, ustawiając wartość domyślną dla tego jednego użytkownika, na przykład:

Defaults:rndcuser        !requiretty
rndcuser ALL = (root) NOPASSWD: /path/to/rndc reload, /path/to/dnssec-keygen, /path/to/other/program

3. Jeśli chcesz zażądać TTY dla wszystkich poleceń oprócz tego jednego polecenia tego jednego użytkownika

Jest to nieco bardziej złożone, ze względu na składnię pliku sudoers. Musisz utworzyć alias polecenia dla polecenia, a następnie ustawić domyślny alias polecenia, na przykład:

Cmnd_Alias RNDC_CMD = /path/to/rndc reload, /path/to/dnssec-keygen, /path/to/other/program
Defaults!RNDC_CMD !requiretty
rndcuser ALL = (root) NOPASSWD: RNDC_CMD

Tak. sudo można skonfigurować bardzo elastycznie. Mimo to muszę wspomnieć: tego typu rozwiązań nie należy uważać za bardzo bezpieczne i należy ich używać wyłącznie w środowisku współpracy, w którym obowiązują inne mechanizmy kontrolne (w ten sposób możesz dać te rozszerzone przywileje swojemu lojalnemu podwładnemu, ale nie należy tego robić dla klienta, którego znasz tylko z sieci).

Konfiguracja sudo jest dostępna /etc/sudoersw większości systemów. Możesz dowiedzieć się o jego składni przez Googling lub przez man sudopolecenie.

Nie powinieneś edytować tego pliku bezpośrednio; może to prowadzić do warunków bezpieczeństwa wyścigu. Zamiast tego użyj visudopolecenia (które jest opakowaniem wokół $EDITORzmiennej środowiskowej).

Po skonfigurowaniu sudo możesz łatwo owinąć to wokół widocznych poleceń. To bardzo proste:

1. Utwórz katalog z listą skryptów opakowujących sudo (fe /usr/local/dnsadmin/bin)

2. Utwórz skrypt opakowania dla poleceń, które mają być użyteczne bez sudo. Będzie to bardzo proste polecenie, na przykład /usr/local/dnsadmin/bin/rndcbędzie:

   #!/bin/bash exec /usr/bin/sudo /usr/sbin/rndc "$@"

3. Pobierz ten katalog do ich PATHzmiennej środowiskowej (np. Przez system lub lokalnie .profile).

Chociaż nie jest to ogólne rozwiązanie w konkretnym przypadku, w rndcogóle nie potrzebujesz sudo.

rndcmoże komunikować się z dowolnym namedprocesem za pośrednictwem lokalnego gniazda lub zdalnego portu, używając tajnego klucza do uwierzytelnienia. Domyślnie (lub przynajmniej dla Debiana, którego używam w dystrybucji) ten plik można znaleźć /etc/bind/rndc.keyi jest on zwykle czytelny tylko dla użytkownika bindi grupy bind.

Każdy, kto ma dostęp do odczytu tego pliku klucza (lub jego identycznej kopii), może użyć rndcdo sterowania serwerem BIND, więc najłatwiejszym rozwiązaniem w tym konkretnym przypadku byłoby dodanie użytkownika do bindgrupy.

Zaskakująca liczba typowych demonów ma coś podobnego (osobiście wciąż zastanawiam się nad możliwościami powerdns w tym zakresie, ale na razie wygląda to obiecująco). Jeśli nie chcesz tego robić sudo, musisz sprawdzić, czy to, co chcesz osiągnąć, jest możliwe indywidualnie dla każdego przypadku.

Nie chcesz używać sudo do przyznawania uprawnień roota dla niektórych poleceń. Zamiast tego możesz chmod 4750 konkretnego programu [który może zawinąć polecenie], aby podnieść prawa zwykłego użytkownika do wykonywania go jako root.