Chciałbym utworzyć nowego użytkownika i dać mu dostęp do sudo. Mówiąc konkretnie, chcę, aby używał sudo vim
i edytował httpd.conf. Napisałem to w sudoers:
user ALL=(ALL) /usr/bin/vim /etc/httpd/confs/httpd.conf
Słyszałem jednak, że może to być ryzykowne. Dlaczego to jest problematyczne? Jak poważny jest problem?
vim
użytkownik może swobodnie otwierać i zapisywać w dowolnym pliku, który mu odpowiada./etc/httpd/confs/httpd.conf
. Następnie użyj,chgrp [OPTION] GROUPNAME FILE
aby zmienić własność grupy/etc/httpd/confs/httpd.conf
. Coś jakgroupadd vimportant
utworzyć nową grupę ichgrp -v vimportant /etc/httpd/confs/httpd.conf
zmienić jej własność. yolinux.com/TUTORIALS/LinuxTutorialManagingGroups.htmlsudoers
stronie podręcznika .sudo
dostęp do vima, użytkownik będzie mógł używać vima jako roota. W vim można uruchomić polecenia UNIX ( Jak uruchomić polecenia Unix od wewnątrz vim? ), Więc użytkownik będzie w stanie zrobić coś takiegouseradd <myuser>
,rm -rf /
lub wiele innych rzeczy.Odpowiedzi:
Mimo że ograniczasz argumenty wiersza poleceń, nic nie stoi na przeszkodzie, aby użytkownik używał vima do otwierania, edytowania i nadpisywania dowolnego pliku losowego po uruchomieniu go jako root.
Użytkownik może uruchomić,
sudo vim /etc/httpd/conf/httpd.conf
a następnie:r /etc/sudoers
UWAGA: O ile nie jest to ograniczone przez SELinux, użytkownik może odczytać dowolny plik w ten sposób!user ALL=(ALL) NOPASSWD: ALL
:w /etc/sudoers
Mogę sobie wyobrazić dziesiątki podobnych sposobów, w jakie użytkownik może uzyskać dostęp, zmodyfikować lub zniszczyć system.
Nie będziesz nawet mieć ścieżki audytu, które pliki zostały zmienione w ten sposób, ponieważ zobaczysz tylko, jak edytuje konfigurację Apache w komunikatach dziennika sudo. Jest to ryzyko bezpieczeństwa związane z przyznawaniem
sudo
uprawnień dowolnemu edytorowi.Jest to mniej więcej ten sam powód, dla którego przyznanie uprawnień na poziomie roota sudo do poleceń takich jak
tar
iunzip
często jest niepewne, nic nie stoi na przeszkodzie, aby zamienić zamienniki plików binarnych systemu lub plików konfiguracji systemu w archiwum.Drugie ryzyko, jak zauważyło wielu komentatorów, polega na tym, że
vim
pozwala na ucieczkę powłoki , w której można uruchomić podpowłokę z poziomu vima, która pozwala wykonać dowolne dowolne polecenie . Z poziomu sesji sudo vim będą one uruchamiane jako root, na przykład ucieczka powłoki::!/bin/bash
da ci interaktywną powłokę roota:!/bin/rm -rf /
zrobi dobre historie w pubie.Co zamiast tego zrobić?
Nadal możesz używać,
sudo
aby umożliwić użytkownikom edycję plików, których nie są właścicielami, w bezpieczny sposób.W konfiguracji sudoers możesz ustawić specjalne zarezerwowane polecenie,
sudoedit
a następnie pełną (ścieżkę) nazwę pliku (plików), które użytkownik może edytować:Użytkownik może następnie użyć
-e
przełącznika w wierszu polecenia sudo lub użyćsudoedit
polecenia:Jak wyjaśniono na stronie podręcznika :
sudoers
Instrukcja zawiera również całą sekcję jaki może zaoferować ograniczoną ochronę przed ucieczek powłoki zRESRICT
iNOEXEC
opcji.i
źródło
sudo tar
asudo unzip
także powodowałem problemy. Dziękuję Ci.:!rm -rf /
, ups!echo "user ALL=(ALL) NOPASSWD: ALL" > ~/sudoers; tar cv ~/sudoers | sudo tar xv -C /etc
I bum. Dostęp root do tar jest podatnością.:sh
, a następnie boom, root shellTa konfiguracja pozwala temu użytkownikowi edytować ten plik. W tym celu uruchamia
vim
edytor z uprawnieniami root.Po uruchomieniu
vim
polecenia użytkownik może robić, co chce, za pomocą tego edytora. - Może otworzyć inny plik lub nawet uruchomić powłokę z vima.Dlatego użytkownik może teraz wyświetlać i edytować dowolne pliki oraz uruchamiać dowolne polecenia w systemie.
źródło
Zamki bezpieczeństwa
Niektóre programy, takie jak na przykład
less
,vi
,vim
imore
pozwalają, aby inne programy uruchamiane z wiersza polecenia, co jest znane jako powłoki Shell ucieczki lub ucieczki do interpretera poleceń. W takich przypadkach możesz użyć,NOEXEC
aby uniemożliwić niektórym programom wykonywanie uprawnień innych programów. Przykład:Pozwoliłoby to użytkownikowi na edycję lub uprzywilejowanie widoku dowolnego pliku w systemie z uruchomionym vimem i więcej, ale wyłącza możliwość uruchamiania innych programów z uprawnieniami z interpretera poleceń esc
vim
.Co ważne,
sudo
zawiera kilka blokad bezpieczeństwa (domyślnie), które mogą zapobiegać niebezpiecznym zadaniom, takim jak przekierowanie standardowego wyjścia wykonania programu (STDOUT
) do plików poza katalogiem osobistym użytkownika.Jeśli zdefiniowano w pliku,
/etc/sudoers
że użytkownik może uruchamiać z uprawnieniami/usr/bin/vim
, tj. Coś takiego:sudo
pozwala zdefiniowanemu zwykłemu użytkownikowi działać/usr/bin/vim
na następujące sposoby:Ale należy uniemożliwić uruchomienie vima w następujący sposób:
źródło
Prosta odpowiedź:
Oto polecenie Vima:
Mają teraz powłokę root.
źródło
Jednym z możliwych stopniowych ulepszeń bezpieczeństwa byłoby zastąpienie:
user ALL=(ALL) /usr/bin/vim /etc/httpd/confs/httpd.conf
z
user ALL=(ALL) /usr/bin/rvim /etc/httpd/confs/httpd.conf
a następnie niech
sudo rvim /etc/httpd/confs/httpd.conf
zamiast tego uruchomi użytkownika .Vim obsługuje tryb ograniczony wyzwalany opcją -Z wiersza poleceń lub uruchamiając program jako rvim. Po włączeniu trybu ograniczonego „wszystkie polecenia korzystające z zewnętrznej powłoki są wyłączone”. Takie podejście nie uniemożliwiłoby użytkownikowi użycia
:split file
polecenia ex do otwarcia innych plików, ale przynajmniej zapobiegałoby celowo złośliwym poleceniom powłoki, takim jak:!rm -rf /
.źródło
Zgadzam się z odpowiedzią HBruijna, że uruchamianie vima jako root naprawdę otwiera system bardzo szeroko, a sudoedit byłoby bezpieczniejszym rozwiązaniem.
Ale nawet wtedy twój system prawdopodobnie nadal byłby raczej otwarty. Przynajmniej zakładając, że w oparciu o tę konfigurację zostanie uruchomiony proces apache z uprawnieniami roota. Istnieje milion sposobów na skonfigurowanie apache w taki sposób, aby uruchamiał programy zewnętrzne. Jako jeden przykład rozważ argument potoku zgodny z dyrektywą CustomLog . Podręcznik wyraźnie stwierdza:
Oczywiście, jeśli Twoi użytkownicy mogą napisać konfigurację, mogą zmienić ten program na cokolwiek im się podoba, np. Coś, co uruchamia skrypt powłoki, aby udzielić im dalszych uprawnień.
Z tego powodu niedawno zhakowałem razem sposób korzystania z funkcji w taki sposób, że apache może zyskać specjalną zdolność do łączenia się z uprzywilejowanym portem, nawet jeśli jest on wykonywany jako zwykły użytkownik. W ten sposób użytkownicy mogą edytować konfigurację, a nawet uruchomić serwer, i nadal są w większości bezpieczne. Jedynym problemem jest to, że mogą powiązać dowolny proces na dowolnym adresie IP. Pozostaje pewien stopień zaufania, ponieważ mogą znaleźć sposób na awarię sshd systemu, a następnie uruchomić własną wersję, próbując uzyskać hasło roota.
źródło
Należy zauważyć, że nawet a
sudoedit {.../whatever.conf}
może stanowić zagrożenie bezpieczeństwa.Utwórz skrypt powłoki
/tmp/make_me_root.sh
i wywołaj ten skrypt w pliku konfiguracyjnym. Znam kilka przykładów, w których to podejście działa:
samba -> polecenie tokena log nt
syslog-ng -> program: Wysyłanie wiadomości do aplikacji zewnętrznych
Apache -> CustomLog
Zakładam, że można rozszerzyć tę listę w nieskończoność.
Wszystko, co musisz zrobić, to zrestartować usługę. Oczywiście po rootowaniu przywrócisz takie linie konfiguracji, aby zatrzeć ślady.
źródło
Oczywiście wcale nie jest bezpieczniej. Jak powiedziałem wcześniej sudoedit, jest to najłatwiejszy i najbardziej odpowiedni sposób na zrobienie tego.
Chcę dodać, że vim pozwala na uruchomienie powłoki, więc nie tylko może edytować dowolny plik systemowy, ale także umożliwia uruchamianie powłoki i robienie tam, gdzie chce.
Po prostu spróbuj uruchomić vima i wpisz: sh
źródło