Kiedy Ubuntu pyta o hasło administratora, w jaki sposób decyduje, o którego z administratorów poprosić?

Konfiguruję maszynę Ubuntu (10.10), z której będzie korzystać kilka osób. Jest to wspólna maszyna w małym biurze. Jego główne role to hosting maszyn wirtualnych za pomocą VirtualBox i serwowanie plików za pomocą Samby.

W przypadku Samby należy skonfigurować kilka kont użytkowników, aby różne osoby mogły łączyć się z udziałami Samby z własnych stacji roboczych. Istnieje jednak konto przeznaczone wyłącznie do uruchamiania maszyn wirtualnych, z których będzie korzystać wiele osób. Czasami ludzie próbują robić rzeczy z tym kontem, które wymagają podwyższonych uprawnień - powoduje to wyświetlenie okna dialogowego Gnome „wprowadź hasło użytkownika administracyjnego”. Jednak to okno dialogowe wymaga podania mojego hasła - kiedy konfigurowałem maszynę, moje konto było pierwszym utworzonym kontem, więc wydaje się, że zakładam, że jestem jedynym użytkownikiem, któremu przyznano uprawnienia sudo.

Chcę wyznaczyć innego użytkownika jako „administratora pierwszej instancji”, że tak powiem, i nie może to być użytkownik wspólnego konta, ponieważ każdy musi znać hasło do tego konta, więc chcę, aby jego uprawnienia były ściśle ograniczone. To nie może być moje konto, ponieważ w żaden sposób nie mówię innym osobom mojego hasła i nie będę obecny na stronie wystarczająco często, aby sam je wprowadzić. Jest jednak ktoś, kto może to zrobić osobiście, więc dodałem ich do /etc/sudoers. Jak mogę powiedzieć, że kiedy to Ubuntu wymaga podniesienia uprawnień do czegoś, powinna poprosić o ich uwagę w pierwszej kolejności?

Podsumowując:

• Konta na maszynie: Alice, Bob, Carol, Dave, Eliza.
• Po zainstalowaniu Ubuntu Alice była pierwszym użytkownikiem dodanym podczas procesu instalacji.
• „Dave” to w rzeczywistości konto, z którego korzysta wiele osób, które nie mogą być na nim, /etc/sudoersponieważ jego hasło to wiedza publiczna.
• Bob został ustawiony jako konto „administracyjne” w Gnome i jest odpowiednio wpisany /etc/sudoers- Bob jest szefem tego biura.
• Gdy podejmowane są działania wymagające podwyższonych uprawnień podczas logowania jako Bob, Carol, Eliza lub Dave, system powinien poprosić Boba o poświadczenia.
• Gdy podejmowane są działania wymagające podwyższonych uprawnień podczas logowania jako Alice, system powinien zażądać poświadczeń Alicji (chociaż Alice jest swego rodzaju administratorem systemu buckaroo i ma zwyczaj używania su -rozszerzonych zadań administracyjnych).

Jakie zmiany konfiguracji muszę wprowadzić, aby uzyskać pożądany stan tutaj?

Przede wszystkim należy zauważyć, że uprzywilejowane działania są dozwolone dla użytkownika innego niż root za pośrednictwem dwóch różnych mechanizmów.

1. sudo

2. PolicyKit

Pierwszy z nich jest używany, gdy jawnie uruchomisz polecenie z sudolub element menu, którego polecenie jest opakowane gksu(jak Menedżer pakietów Synaptic ).
W takim przypadku wymagane jest hasło wywołującego użytkownika, zwykle zalogowanego użytkownika.

Drugi jest używany, gdy aplikacja obsługująca PolicyKit próbuje wykonać uprzywilejowaną akcję. W takim przypadku aplikacja pyta władze lokalne PolicyKit (za pośrednictwem D-Bus), czy można wykonać akcję. Władze lokalne następnie za pośrednictwem agenta uwierzytelnienia prosi aktywnego użytkownika o potwierdzenie swojej tożsamości. Okna dialogowe wyglądają następująco (niestety z tekstem w języku włoskim :)

Możesz zidentyfikować PolicyKit na podstawie małego czarnego trójkąta i etykiety Szczegóły . Jak widać, jeśli więcej niż jeden użytkownik jest w admingrupie, możesz wybrać z listy, którego użytkownika użyć do uwierzytelnienia.

Biorąc to wszystko pod uwagę, zarówno sudoPolicyKit , jak i konfiguracje są znacznie bardziej skomplikowane, jeśli chodzi o konfiguracje, które można osiągnąć: możesz skonfigurować akcję, która może być wykonana bez hasła, wykonywana tylko przez określonego użytkownika lub grupę itp.

Jeśli chodzi o twoje pytanie, gdy mechanizmem używanym przez aplikację jest PolicyKit, niezależnie od aktualnie zalogowanego użytkownika, wymagane hasło to Bob lub Alice (jedyny administrator, jeśli dobrze rozumiem), i możesz to zmienić z listy, którego użytkownika chcesz użyć do uwierzytelnienia.

Gdy mechanizmem wykorzystywanym przez aplikację jest sudo(w przypadku zadań administracyjnych wykonywanych za pomocą GUI staje się to coraz rzadsze), nie masz natychmiastowego i prostego sposobu na wybranie użytkownika do uwierzytelnienia.

Najwyraźniej sudobyłby to dla mnie pierwszy wybór w takim przypadku. Głównymi punkt pojawi się, że większość (rzeczywista) administratorzy rzeczywistości nie używać /etc/sudoersdo jego najszerszym zakresie ( User_Alias, Runas_Alias, Host_Alias, Cmnd_Alias).

Większość administratorów używa tylko niektórych istniejących reguł i dodaje użytkowników lub, co gorsza, po prostu dodaje użytkowników do sudogrupy, dla której reguła zwykle istnieje w konfiguracjach Ubuntu ( %sudo...). To oczywiście daje odpowiednim użytkownikom wolne panowanie i pełną moc konta superużytkownika.

Biorąc pod uwagę twój komentarz:

więc dodałem je do /etc/sudoers

Sądzę, że również nie wykorzystujesz tego w możliwym zakresie.

W scenariuszu takim jak twój dosłownie napisałbym kilka działań, do których Bob ma się ograniczyć. W rzeczywistości tak zrobiłem na serwerze, który utrzymuję, aby umożliwić dwóm określonym użytkownikom ponowne uruchomienie określonego gościa KVM na hoście. Skrypty zawierałyby hashbang z bezwzględną ścieżką do interpretera (np. #!/bin/dashZamiast #!/usr/bin/env bash) i prawdopodobnie działałyby z powłoką używaną gdzie indziej do zadań uprzywilejowanych ( /bin/dashlub /bin/sh). To tylko środki ostrożności. Poza tym upewniłem się, że na stałe wpisałem wszystkie bezwzględne ścieżki do plików binarnych i użyłem ich jak najmniej. Np. Przy użyciu bash/ dashWolę builtins niż commands (patrz man bash). Można to utrzymać, przypisując zmiennej ścieżkę bezwzględną i odnosząc się do programu na podstawie tej zmiennej ($VIRSHzamiast /usr/bin/virsh). Jeśli możesz, sprawdź kod wszystkich zewnętrznych skryptów przed ich wywołaniem. Zwłaszcza jeśli chcesz do nich zadzwonić w uprzywilejowanym kontekście. W moim przypadku ograniczam również użytkowników do określonego katalogu głównego i określonego podsystemu SSH, ponieważ łączą się oni tylko z maszyną za pomocą sshduwierzytelniania za pomocą klucza publicznego. Oczywiście nie potrzebujesz tego.

Upewnij się, że chown root: <the-script>; chmod u=rw,a=,a+rx <the-script>nikt nie rootjest w stanie majstrować przy nim. Ponadto należy zachować ostrożność ze setuidi setgidbity włączone binariów docelowych ( findmoże być użyty do ich wykrycia). Załóżmy na moment, w którym znajduje się skrypt /usr/sbin/priv-action.

Teraz edytuj swój /etc/sudoers. noexecmoże być użyty, aby zapobiec również innym plikom binarnym, niż te wyraźnie dozwolone. W rzeczywistości istnieje wiele dodatkowych ustawień, nie tylko te, które tu opisuję. Więc koniecznie skonsultuj się man sudoers.

Teraz wolę nazywać użytkowników ( User_Alias) w moim sudoerspliku, ale równie dobrze możesz użyć Group_Alias( man sudoers) lub rzeczywistej grupy systemowej (np. %sudo):

# The list is comma-separated: bob,alice,...
User_Alias      LIMITED_ADMINS=bob

a następnie dodaj alias polecenia, aby umożliwić wykonanie tego konkretnego skryptu:

# The list is comma-separated: /usr/sbin/priv-action,/bin/bash,...
Cmnd_Alias      PRIV_ACTION=/usr/sbin/priv-action

Na koniec pojawia się magiczna linia pozwalająca bob(a raczej użytkownikom wymienionym poniżej LIMITED_ADMINS) na wykonywanie uprzywilejowanych poleceń za pomocą skryptu:

LIMITED_ADMINS  ALL=(root) PRIV_ACTION

W przeciwieństwie do poprzednich definicji aliasów ten wiersz wymaga wyjaśnienia. Najpierw zagłębmy się w części w wierszu „Specyfikacja użytkownika”. Tutaj man sudoerspomaga:

Podstawowa struktura specyfikacji użytkownika to who where = (as_whom) what.

Przykładowa linia (znaleziona w większości konfiguracji Ubuntu):

root    ALL=(ALL) ALL

Oznacza to, że użytkownik o nazwie root (użyj, #0aby powiązać go z UID 0) może na wszystkich hostach działać w dowolnym kontekście użytkownika, ale zostanie poproszony o podanie hasła (przy założeniu domyślnego zachowania). Dodanie NOPASSWDtagu przed ostatnim ALLpozwoliłoby również rootzrobić to samo bez pytania o hasło (tak:) root ALL=(ALL) NOPASSWD:ALL. ALLjest nieodłącznym aliasem wieloznacznym dla różnych typów aliasów.

Ale wracając do Boba:

LIMITED_ADMINS  ALL=(root) PRIV_ACTION

pozwoli bobi innym wymienionym członkom User_Alias LIMITED_ADMINSna uruchomienie (na wszystkich hostach, po to ALLjest) dla użytkownika root(implikowana grupa, ale można podać, zobacz man sudoers) polecenia podane w Cmnd_Alias PRIV_ACTION. To staje się lepsze. Nadal zakładając, że piszesz ten skrypt, możesz zezwolić na różne parametry, unikając w ten sposób pisania wielu skryptów. /etc/sudoerschętnie przyjmuje podobne do powłoki symbole wieloznaczne, aby ograniczyć możliwości przekazywania argumentów.

Konsekwentnie stwierdzam, że administratorzy nie używają sudoerssposobu, w jaki powinien być używany, dlatego doceniłem odpowiedni „hack” z dwóch książek „Linux Server Hacks” i „Linux Server Hacks Tom drugi”, od których zacząłem bardziej wyrafinowane wykorzystanie tego wspaniałego obiektu.

Możesz wymyślić wszelkiego rodzaju skomplikowane - co może nie do końca pomóc w aspekcie bezpieczeństwa - rozwiązania dla twojego konkretnego przypadku, ale kiedy mówisz podstawowe słownictwo /etc/sudoers, możesz wykonywać całkiem magiczne wyczyny :)

Uwaga: pamiętaj, że możesz również utworzyć nowy plik, /etc/sudoers.d/jeśli masz na to ochotę. Zakłada się, że /etc/sudoerszawiera on linię:

#includedir /etc/sudoers.d

W Uniksie / Linuksie jest tylko jeden superużytkownik, jego nazwa to root, ale sudoers to użytkownicy, którzy mogą zostać rootem. Powinieneś używać grup:

newgrp admins

a następnie przypisz użytkowników do tej grupy:

chgrp alice admins

następnie dodaj grupę adminów do pliku konfiguracyjnego sudoers, tak jakby grupa była użytkownikiem.

Aktualizacja

Lub możesz dodać dowolnego użytkownika do grupy administracyjnej:

chgrp alice admin