Sudo nie ma żadnego konkretnego celu w zakresie ochrony przed złośliwymi osobami trzecimi. Więc tak, jest to w zasadzie bezużyteczne do tego celu. W przeszłości uważałem, że w rzeczywistości jest to kontrola bezpieczeństwa mająca na celu zapobieganie eskalacji przywilejów i utrudnianie ataków, ponieważ niektórzy ludzie upierają się, że ma ona również taki cel, ale w rzeczywistości jest to fałszywe. W rzeczywistości w tej chwili otrzymałeś tylko jedną odpowiedź na swoje pytanie, a ta odpowiedź propaguje ten mit. Jedynym celem sudo jest ochrona przed samym sobą, czyli uniknięcie przypadkowego zepsucia systemu. Uzyskanie wszystkich przywilejów jednym kliknięciem lub jednym naciśnięciem klawisza może być niebezpieczne, a sudo przynajmniej zmusi Cię do świadomego wpisania hasła. A jeśli Ty (lub program lub skrypt) przez pomyłkę dotkniesz plików systemowych lub plików innych użytkowników, bez świadomego użycia sudo , otrzymasz powiadomienie o odmowie uprawnień. W końcu jest to tylko narzędzie administracyjne, a nie kontrola bezpieczeństwa, która ma chronić Cię przed atakiem.

Oto bardzo podstawowy przykład, dlaczego sudo nie zapewnia prawdziwej ochrony przeciwko złośliwemu kodowi:

  # Utwórz ładunek: zamień sudo na aliaspayload = 'fake_sudo () {# Symuluj monit sudo echo -n "[sudo] hasło dla $ {USER}:" przeczytaj -s hasło echo # Uruchom komendę, żebyś był zadowolony echo "$ password" | sudo -S "$ @" # Rób moje złe rzeczy swoim hasłem echo "Gotowe z twoim poleceniem, teraz mogę użyć $ password, żeby robić co chcę"} alias sudo = fake_sudo '# Zapisz ładunek do pliku konfiguracyjnego bashrcecho " $ payload ">> ~ / .bashrc  

To bardzo podstawowy przykład kodu, który osoba atakująca może uruchomić na Twoim komputerze. Nie jest doskonały, nie obsługuje nawet wszystkich przypadków (nie zadziała dobrze, jeśli wprowadzisz złe hasło), ale po prostu pokazuje, że sudo może zostać zastąpione przez atakującego. Jeśli uruchomisz ten skrypt, następnym razem, gdy otworzysz terminal i uruchomisz sudo , w rzeczywistości uruchomisz fake_sudo . Atakujący może zamienić Twoje programy na aliasy lub zastąpić pliki binarne (umieszczając złośliwe wersje w ~ / bin lub w innym miejscu, w którym mogą zostać wykonane na Twojej ścieżce) itd.

To nie jest nawet prawdziwą „eskalacją uprawnień”, ponieważ użytkownik, który może uruchomić sudo , aby zostać rootem, ma już wszystkie uprawnienia. Prawdziwy nieuprzywilejowany użytkownik nie powinien mieć możliwości sudo . Aby mieć rzeczywisty rozdział uprawnień, powinieneś uruchomić administrację na zupełnie oddzielnym koncie.

Jestem współautorem sudo. Został napisany na początku lat 80-tych, aby odpowiedzieć na potrzebę ochrony integralności współdzielonego zasobu (VAX-11/750 z systemem BSD UNIX) przed jego użytkownikami (wydział CS w SUNY / Buffalo). W tamtym czasie jedyną inną opcją było „su”, które wymagało od wszystkich wspólnego hasła. Gdyby doszło do katastrofy, byłoby trudne lub niemożliwe przeszukanie kryminalistyki i ustalenie, kim był sprawca o grubych palcach ...

Myślę, że pozornie trwałą użytecznością sudo jest to, że przypomina użytkownikowi wiersza poleceń mają zamiar zrobić coś, co może zasłużyć na pewną pewność wyniku przed wpisaniem. To prawda, w niektórych implementacjach, takich jak główne dystrybucje raspberry pi, w których nie jest wymagane podanie hasła, służy jedynie jako pieczątka. Więc zrób rysunek.

Nadal uważam, że najlepsze praktyki wdrażania aplikacji w systemach operacyjnych wywodzących się z UNIX nakazują uruchamianie ich z identyfikatorem innym niż root. Jeśli potrzebujesz roota, powinno to być w kontrolowanych warunkach. Pomyśl o sudo jako sposobie nadawania uprawnień roota użytkownikom wiersza poleceń w kontrolowanych okolicznościach. To wszystko.

Nie, sudo nie jest bezużyteczne.

Jako użytkownik (cel)

Zwykle, gdy jesteś w systemie Linux działasz jako użytkownik inny niż root. Wiele rzeczy, takich jak instalowanie pakietów za pomocą apt , wymaga uprawnień root / sudo . Plik binarny sudo jest po to, aby nadać zwykłym użytkownikom uprawnienia do wykonywania działań na poziomie root , takich jak apt install .

Powinieneś nie używaj Linuksa cały czas jako root . Dzieje się tak, ponieważ osoba atakująca miałaby dostęp root do twojego systemu, co oznacza, że ​​może zrobić praktycznie wszystko w twoim systemie. Zamiast tego uruchamiasz Linuksa jako użytkownik inny niż root, więc nawet jeśli twoje konto zostanie przejęte, osoba atakująca nie może natychmiast uzyskać dostępu root .

Oczywiście żaden system jest całkowicie bezpieczny i coś w twoim systemie może zostać wykorzystane. Korzystanie z konta sudoers zamiast root to jeden krok w zabezpieczaniu systemu, jak omówiono powyżej.

Jeśli mówisz „Haker dostanie i mimo wszystko uzyskać roota, dlaczego w ogóle powinienem używać sudo ? ”, to tak, jakby powiedzieć„ Jeśli ktoś wejdzie do mojego domu, i tak będzie mógł (w jakiś sposób) zdobyć moją biżuterię. Dlaczego powinienem używać sejfu lub zamków? ”. To dodatkowa warstwa ochrony. Nie szukamy „kłódki, która może chronić wszystko” , ale „wielu zamków zapewniających dodatkowe bezpieczeństwo na wypadek, gdyby kilka z nich się złamało” .

sudo to zabezpieczenie. Umożliwia uruchamianie programów na poziomie administratora tylko wtedy, gdy jest to konieczne. Dlatego tylko czasami otwierasz drzwi do swojego pokoju ŚCIŚLE TAJNE zamiast zawsze je otwierać, nawet jeśli masz je zawsze otwarte (zawsze otwarte jako root) jest wygodniejsze.

Ponadto, jeśli jesteś uprawnionym użytkownikiem, nie uruchamiasz skryptów eskalacji uprawnień za każdym razem, gdy chcesz użyć akcji sudo , używasz sudo.

Jako atakujący

Plik binarny sudo może zostać wykorzystany do uzyskania pewnych informacji lub nawet uzyskania dostępu root . Czasami użytkownicy mogą mieć w swoim pliku sudoers coś takiego jak MY_USER ALL = (ALL) NOPASSWD: ALL , w takim przypadku, jeśli możesz uzyskać dostęp jako użytkownik MY_USER , możesz uruchomić dowolne i wszystkie polecenia sudo / root bez haseł. Uruchomienie sudo -l może również dać ci informacje, takie jak polecenia, które możesz uruchomić jako root nawet bez hasła. Przykładem takiej błędnej konfiguracji może być USERNAME ALL = (ALL) NOPASSWD: / bin / vi , która umożliwia uruchomienie vi jako root bez hasła jako użytkownik NAZWA UŻYTKOWNIKA . To jeden ze sposobów ręcznej eskalacji uprawnień.

Każdy dodatkowy program może zawierać dodatkowe luki w zabezpieczeniach. Uruchomienie tomcat wprowadziłoby system do exploitów tomcat. sudo może być po prostu kolejnym programem, którego możesz użyć w swojej eksploatacji.

Ponadto, jak myślisz, w jaki sposób te przydatne skrypty / narzędzia do eskalacji uprawnień zapewniają dostęp do konta roota? Wiele z nich używa sudo w taki czy inny sposób.

Sudo nie jest bezużyteczna.

Administrator może elastycznie i szczegółowo przypisywać uprawnienia oraz mieć opcje odpowiedzialności (przyzwoite logowanie). Jest to znacznie lepsze rozwiązanie do korzystania z grup.

Oczywiście, jeśli porównasz je z SELinux , wydajność i możliwości sudo zaćmienia, choć przy ogromnym koszt wdrożenia i konfiguracji (i utrzymania).

I odwrotnie, z punktu widzenia atakującego, może on mieć szczęście i zdobyć konto z uprawnieniami sudo lub skorzystać z błędnej konfiguracji . Wciąż wysiłek włożony w eskalację ze standardowego użytkownika z uprawnieniami sudo do roota może być znaczący. Z drugiej strony, żaden z tych problemów nie jest spowodowany przez samo sudo .

Jednak jego skuteczność jest całkowicie zależna od konfiguracji. Uwolnienie hosta jest trywialne, jeśli złamane konto standardowe może uruchamiać cokolwiek jako root bez hasła; jest to trudniejsze, ale całkiem wykonalne, jeśli zezwala się na uruchamianie pewnych poleceń, którymi można manipulować dość trudne, jeśli tylko starannie wybrane pliki binarne i sytuacje mogą być wykonywane jako root.

Również sudo może być używane do uruchamiania poleceń tak jak inni użytkownicy niż root , więc jest to kolejny sposób użycia sudo , który może nie doprowadzić do pełnego naruszenia bezpieczeństwa systemu.

sudo jest równie bezpieczne lub niepewne, jak jego popularne alternatywy, takie jak su.

Najpopularniejsza alternatywa sudo to zezwolenie niektórym lub wszystkim użytkownikom na podniesienie ich uprawnień za pomocą su . Najczęściej wszyscy użytkownicy mogą to zrobić, pod warunkiem że znają hasło użytkownika docelowego . W przeciwieństwie do sudo , które prawie zawsze wymaga podania hasła użytkownika (i jest ograniczone tylko do zaufanych użytkowników), su wymaga hasła użytkownika docelowego .

Niektórzy uważają, że dzięki temu su jest bezpieczniejszy niż sudo , ale tak nie jest. su jest przedmiotem tego samego rodzaju ataków, co sudo . Załóżmy, że jesteś użytkownikiem, który czasami uruchamia su , aby zostać rootem. Załóżmy ponadto, że osoba atakująca, która nie zna hasła roota i nie może jeszcze wykonywać działań jako użytkownik root, mimo to udaje się wykonać dowolny kod z konta użytkownika innego niż root. Tak jak ten atakujący może sprawić, że po uruchomieniu sudo uruchomisz jego złośliwe polecenie, tak samo może on sprawić, że po uruchomieniu su you ' uruchomią swoje złośliwe polecenie.

Oznacza to, że technika w odpowiedzi reeda działa równie dobrze, aby wprowadzić fałszywe polecenie su , które przechwytuje hasło docelowym użytkownikiem (którym, gdy su jest używany do administrowania systemem, jest zwykle root).

Ale można zrobić coś lepszego niż jedno i drugie, lub w celu zminimalizowania ryzyka.

Gdy ktoś będzie mógł wykonać dowolne polecenia tak jak Ty, zwykle może wprowadzić dowolne zmiany w sposobie zachowania powłoki, a tym samym utworzyć fałszywe sudo , > su , doas lub jakiekolwiek inne polecenia zwiększające uprawnienia.

Jednakże, o ile możesz uniknąć interakcji z fałszywym ekranem logowania , możesz temu zaradzić, mając osobne konta użytkowników administracyjnych i nieadministracyjnych. To nie brzmi jak nowy pomysł i oczywiście nie jest, ale jest zaskakujące, jak rzadko jest to wykonywane naprawdę .

Twoje konto administracyjne może po prostu bądź kontem roota. Ale jeśli chcesz skorzystać z zalet niezalogowania się jako root, które obejmują logowanie (w celu ustalenia, co poszło nie tak w przypadku niezłośliwych błędów) i możliwość uruchamiania programów, które nie są przeznaczone do uruchamiania jako root (większość interfejsy graficzne), możesz mieć dwa konta inne niż root, z których jedno jest używane do administrowania (w których uruchamiasz sudo lub su w razie potrzeby), a drugie których nie.

To konto powinno, jeśli oczywiście nie dzielić poświadczenia dostępu z kontem nieadministracyjnym. Nie powinny mieć identycznych ani podobnych haseł i powinny mieć oddzielne pary kluczy. Ponadto nie możesz podwyższać uprawnień z konta nieadministracyjnego do konta administratora, z tego samego powodu nie możesz podwyższać uprawnień z konta nieadministracyjnego do konta root.

Jeśli to zrobisz, pojawi się nawet argument dla sudo zamiast jego alternatyw.

W tej konfiguracji jest zaletą sudo w porównaniu z su , choć nie jest to decydująca korzyść. Możesz uniknąć przypadkowego użycia niewłaściwego konta - tego, które jest używane do wszelkiego rodzaju innych rzeczy nieadministracyjnych, które mogą narazić go na większe ryzyko - do administrowania systemem, czyniąc go zwykłym kontem ograniczonego użytkownika którego nie ma na liście i nie należy do żadnej z wymienionych grup w pliku / etc / sudoers .

Ale możesz również osiągnąć ten cel za pomocą su , albo ćwicząc odpowiednią samodyscyplinę i upewniając się, że nigdy nie korzystasz z su z konta, które zaprojektowałeś jako nieadministracyjne lub uniemożliwiając kontom wyznaczonym jako nieadministracyjne podnoszenie uprawnień za pomocą su . (Jednym ze sposobów na osiągnięcie tego w systemie GNU / Linux jest AppArmor, dzięki czemu Ubuntu uniemożliwił kontowi gościa kiedykolwiek pomyślne użycie su - w wersjach Ubuntu, które były dostarczane z konta gościa włączone.)

Ryzyko używania sudo lub su w zwykły sposób może być dla Ciebie akceptowalne.

Biorąc to wszystko pod uwagę, nie mówię, że koniecznie musisz to zrobić. To zależy od Ciebie lub, w stosownych przypadkach, od Ciebie i innych interesariuszy.

Dla wielu osób ryzyko związane z używaniem tego samego konta jest (a) podniesione do rangi root z sudo (lub podobne mechanizmy, takie jak Polkit) lub su (lub podobne mechanizmy, takie jak doas ), które są używane dla (b) zadania nieadministracyjne, takie jak uruchamianie przeglądarki internetowej, mogą być akceptowalnym kosztem wygody.

Celem sudo jest nie utrudnianie podnoszenia uprawnień. W rzeczywistości jest dokładnie odwrotnie: chodzi o to, aby łatwe podniesienie uprawnień.

Ułatwiając podnoszenie uprawnień wtedy, gdy ich potrzebujesz , użytkownicy są mniej skłonni do uruchamiania z podwyższonymi uprawnieniami zawsze.

Jeśli utrudniasz podniesienie uprawnień, użytkownicy będą logować się jako root przez cały czas. Ułatwiając podnoszenie uprawnień „w locie”, zachęca się użytkowników do logowania się jako użytkownicy nieuprzywilejowani i do podnoszenia uprawnień tylko dla pojedynczego procesu na czas trwania tego procesu, zamiast ciągłego uruchamiania z podwyższonymi uprawnieniami.

sudo jest zasadniczo narzędziem użyteczności , a nie narzędziem bezpieczeństwa. Efekty bezpieczeństwa sudo to drugorzędne konsekwencje efektów użyteczności. Zabezpieczenia nie są przydatne, gdy nie są użyteczne.

W tym przypadku sudo jest z grubsza odpowiednikiem UAC w systemie Windows Vista +, który jest często błędnie rozumiany jako narzędzie zapobiegające podniesieniu uprawnień, podczas gdy w rzeczywistości jest to narzędzie ułatwiające podniesienie uprawnień. Przed wprowadzeniem UAC było całkowicie normalne, że użytkownicy systemu Windows zawsze logowali się na konto z uprawnieniami administratora, po prostu dlatego, że w przypadku innych zastosowań biurowych system Windows był bezużyteczny.

Jest dodatkowa zaleta do sudo przez su lub logując się jako root , co oznacza, że ​​ sudo można skonfigurować tak, aby pozostawił ślad audytu z których użytkownik wydał jakie uprzywilejowane polecenie i kiedy.

Podobnie jak wszystko w zakresie bezpieczeństwa informacji, sudo jest wyłączeniem sprzedaży .

Zbadajmy alternatywy:

• zmiana systemu, aby polecenia, których używasz sudo , nie wymagają uprawnień roota
• zalogowanie się jako root, aby uzyskać wymagane prawa dostępu
• użycie su do przełączenia się na powłoka roota
• uruchomienie samego polecenia jako root, bez względu na to, kto je wykona

bez wchodzenia w szczegóły, mam nadzieję, że zgodzisz się, że wszystkie te alternatywy są gorsze niż sudo . Nie jest doskonały, można go zaatakować - ale jest to najlepsza z tych alternatyw.

Jeśli chodzi o SELinux, nie zapominaj, że pojawił się on w programie stosunkowo późno. Nie pamiętam, który rok (i do diabła, tam byłem, moje imię jest w poświadczeniach SELinux), ale sudo znacznie poprzedza SELinux.

I chociaż SELinux jest bez wątpienia potężniejsza i bezpieczniejsza alternatywa, większość administratorów nie jest w stanie napisać właściwej polityki bezpieczeństwa SELinuksa.

Tak więc, biorąc pod uwagę kilka całkiem złych wyborów, sudo jest w wielu przypadkach najmniej złym. To lepsze niż nic lub alternatywy i to jest wystarczający powód. Żadne zabezpieczenia i tak nie są doskonałe.

Wszystko to powiedziawszy, głównym zastosowaniem sudo w przedsiębiorstwie nie jest bezpieczeństwo, ale odpowiedzialność . Jeśli administratorzy muszą zalogować się za pomocą konta osobistego, a następnie używać sudo do swojej codziennej pracy, śledzenie, kto co zrobił, jest trywialne. Korzystając z auditd, możesz śledzić je również wtedy, gdy używają su .

Zależy to od tego, jak skonfigurujesz sudo:

Na komputerze używanym przez różne osoby możesz skonfigurować sudo w taki sposób, że niektórzy użytkownicy można uzyskać dostęp do niektórych poleceń za pomocą sudo:

sudo można skonfigurować w taki sposób, aby niektórzy użytkownicy mogli wykonać określone polecenie (np. ip ) używając sudo - ale nie żadnego innego polecenia.

Inną rzeczą jest to, że sudo powinno być skonfigurowane w taki sposób, o jaki zostaniesz zapytany na hasło. Nawet jeśli atakujący ma dostęp do konsoli, zostanie poproszony o podanie hasła, jeśli wpisze sudo przykładowe polecenie .

Możesz także skonfigurować sudo w taki sposób, że niektóre polecenia (np. ip ) nie wymagają hasła, a wszystkie inne wymagają wpisania hasła.

Można również skonfigurować sudo w taki sposób, że hasło wymagane dla sudo różni się od hasła logowania.

W tym przypadku nawet hasło logowania nie pomoże atakującemu. .

Jeśli jednak skonfigurujesz sudo w taki sposób, że możesz wykonywać wszystkie polecenia i nie zostaniesz poproszony o podanie hasła, to sudo nie zapewniają żadnych zabezpieczeń.

Prawie wszystko bez klucza Secure Attention jest `` prawie bezużyteczne ''.

Reed daje doskonałą odpowiedź, dlaczego sudo (a przynajmniej jego funkcja hasła) jest prawie bezużyteczna ze względów bezpieczeństwa. Jednak to nie tylko błąd w sudo , bash czy nawet w całym środowisku Unix. Jest to ogólny problem z uzyskaniem wyższych uprawnień przy użyciu hasła bez użycia techniki pozwalającej uniknąć fałszywych monitów logowania.

Na początek zsh , fish , a nawet wiersz poleceń systemu Windows pozwala dostosować uruchamiane polecenie, więc przełączenie się na inną powłokę nie powstrzyma atakującego przed zastąpieniem fake_sudo sudo przez sudo .

To nie jest tylko środowisko uniksowe. Wyobraź sobie, że na przykład Windows, przechodzisz do Start> Zmień profil i wpisujesz hasło administratora. Opps, atakujący zamienił Explorer.exe na fake_Explorer.exe , to nie był prawdziwy przycisk Start, który naciśnąłeś. Atakujący znowu ma Twoje hasło administratora.

Do tych celów czasami używany jest Bezpieczny klucz ostrzegawczy. Czasami możesz zobaczyć ekran logowania do systemu Windows, na którym pojawia się komunikat „Naciśnij Ctrl-Alt-Del”, aby się zalogować. Dzieje się tak, ponieważ Ctrl-Alt-Del przechodzi bezpośrednio do systemu operacyjnego i nie może zostać sfałszowany przez fałszywą powłokę logowania. Ponieważ Ctrl-Alt-Del może być użyty do bezpiecznego zwrócenia uwagi systemu operacyjnego, nazywa się to Bezpiecznym kluczem ostrzegawczym.

Istnieją pewne alternatywy dla bezpiecznego klucza ostrzegawczego. Na przykład możesz wybrać obraz, który spodziewasz się zobaczyć po zalogowaniu. Lepiej nie przechowywać tego obrazu w miejscu, w którym nieuprzywilejowane procesy mogą go odczytać lub wyświetlić, gdy nieuprzywilejowane procesy mogą to zrobić. Więc to nadal wymaga oddzielenia ekranu logowania od nieuprzywilejowanego ogólnego konta roboczego w sposób, w jaki narzędzia takie jak sudo tego nie robią.

Kiedyś miałem problem z zalogowaniem się do mojego serwera za pomocą kluczy SSH i zapomnieniem hasła do użycia z sudo , co sugeruje ten pomysł:

Przypuszczam, że jeśli ktoś włamie się Poświadczenia SSH, powiedzmy odzyskane z wyczyszczonego dysku twardego na śmietniku, a następnie sudo może pomóc, ponieważ hasło jest potrzebne do wykonywania funkcji administratora. Nie mam dowodów, ale podejrzewam, że wiele kluczy SSH nie ma do nich hasła.

Bardziej realistycznym wektorem ataku z tym problemem sudo są klucze SSH pozostawione na Github.

Coś, o czym nikt do tej pory nie wspominał, to fakt, że sudo (przez PAM) może używać innych mechanizmów niż hasło i / lub używać uwierzytelniania dwuskładnikowego. Chociaż nie rozwiązuje to problemu z zagrożonym kontem, utrudnia to sfałszowanie monitu.

Dodatkowo sudo ma swoje zastosowania poza zwykłym udzielaniem pełnego dostępu do konta roota, może być użyte, aby umożliwić określonemu użytkownikowi uruchamia określone polecenie i nie ma innego jako root, ani nawet jako inny użytkownik. Nie jestem pewien, czy SELinux byłby tak łatwy do skonfigurowania w tym przypadku.