Dlaczego świat Su jest wykonywalny?

Mam bezgłowy serwer, który jest zalogowany zdalnie przez wielu użytkowników. Żaden z pozostałych użytkowników nie ma w pliku sudoers, więc nie mogą uzyskać roota sudo. Ponieważ jednak uprawnienia susą włączone -rwsr-xr-x, nic nie powstrzymuje ich przed próbą brutalnego wymuszenia hasła roota.

Można argumentować, że jeśli użytkownik zna hasło roota, i tak może narazić system na szwank, ale nie sądzę, że tak jest. OpenSSH jest skonfigurowany z PermitRootLogin noi PasswordAuthentication noi żaden z pozostałych użytkowników nie ma fizycznego dostępu do serwera. O ile wiem, świat wykonujący zezwolenie na /usr/bin/suto jedyna droga dla użytkowników próbujących uzyskać root na moim serwerze.

Co mnie jeszcze bardziej zastanawia, ponieważ nie wydaje się nawet przydatne. To pozwala mi biegać subezpośrednio zamiast tego robić sudo su, ale nie jest to żadna niedogodność.

Czy coś przeoczyłem? Czy świat wykonuje zezwolenie sutylko na to z przyczyn historycznych? Czy są jakieś wady usuwania tego uprawnienia, którego jeszcze nie spotkałem?

Jednym z brakujących punktów w odpowiedzi ilkkachu jest to, że podniesienie do roota jest tylko jednym konkretnym zastosowaniem su. Ogólnym celem su jest otwarcie nowej powłoki pod kontem logowania innego użytkownika. Tym innym użytkownikiem może być root(i być może najczęściej), ale sumożna go wykorzystać do przyjęcia dowolnej tożsamości, którą system lokalny może uwierzytelnić.

Na przykład, jeśli jestem zalogowany jako użytkownik jimi chcę zbadać problem, który mikezostał zgłoszony, ale którego nie jestem w stanie odtworzyć, mogę spróbować zalogować się jako mikei uruchomić polecenie, które przysparza mu problemów.

13:27:20 /home/jim> su -l mike
Password:(I type mike's password (or have him type it) and press Enter)
13:27:22 /home/mike> id
uid=1004(mike) gid=1004(mike) groups=1004(mike)
13:27:25 /home/mike> exit  # this leaves mike's login shell and returns to jim's
13:27:29 /home/jim> id
uid=1001(jim) gid=1001(jim) groups=1001(jim),0(wheel),5(operator),14(ftp),920(vboxusers)

Użycie -lopcji supowoduje symulację pełnego logowania (na manstronę).

Powyższe wymaga jednak znajomości mikehasła. Jeśli mam sudodostęp, mogę zalogować się mikenawet bez jego hasła.

13:27:37 /home/jim> sudo su -l mike
Password:(I type my own password, because this is sudo asking)
13:27:41 /home/mike>

Podsumowując, powodem, dla którego uprawnienia do supliku wykonywalnego są pokazane, jest to, że sujest to narzędzie ogólnego zastosowania, które jest dostępne dla wszystkich użytkowników w systemie.

Historycznie (na unikach GNU) nie było, a przynajmniej ręcznie sprawdzane, czy jesteś w grupie o nazwie „koło” su. Wersja GNU sunie odtwarzała tej funkcji z powodu ideologii RMS dotyczącej kontroli dostępu w tym czasie:

Why GNU `su' does not support the `wheel' group
===============================================

   (This section is by Richard Stallman.)

   Sometimes a few of the users try to hold total power over all the
rest.  For example, in 1984, a few users at the MIT AI lab decided to
seize power by changing the operator password on the Twenex system and
keeping it secret from everyone else.  (I was able to thwart this coup
and give power back to the users by patching the kernel, but I wouldn't
know how to do that in Unix.)

   However, occasionally the rulers do tell someone.  Under the usual
`su' mechanism, once someone learns the root password who sympathizes
with the ordinary users, he or she can tell the rest.  The "wheel
group" feature would make this impossible, and thus cement the power of
the rulers.

   I'm on the side of the masses, not that of the rulers.  If you are
used to supporting the bosses and sysadmins in whatever they do, you
might find this idea strange at first.

Możesz znaleźć o wiele więcej na ten temat w Googling „wheel group rms” lub podobnym.

Ponieważ jednak uprawnienia susą włączone -rwsr-xr-x, nic nie powstrzymuje ich przed próbą brutalnego wymuszenia hasła roota.

Tak. Zakładając, że używasz zwykłego systemu Linux, pam_unix.somoduł opóźnia nieudaną próbę uwierzytelnienia o ~ dwie sekundy, ale nie sądzę, aby było coś, co mogłoby powstrzymać jednoczesne próby.

Nieudane próby są oczywiście rejestrowane:

Aug 16 22:52:33 somehost su[17387]: FAILED su for root by ilkkachu

Brutalne wymuszanie hasła powinno być wyraźnie widoczne w logach, jeśli masz jakiś system do ich monitorowania. A jeśli masz niezaufanych lokalnych użytkowników, być może powinieneś. Niezaufani użytkownicy lokalni mogą również próbować wykorzystać jakiekolwiek exploity związane z eskalacją uprawnień tylko na poziomie lokalnym, i są one znacznie częstsze niż zdalne eskalowanie uprawnień.

Co jeszcze mnie zastanawia, że ​​to nawet nie wydaje się przydatne.

Oczywiście jest to przydatne, pozwala podnieść się do poziomu root, jeśli znasz hasło.

To pozwala mi biegać subezpośrednio zamiast tego robić sudo su, ale nie jest to żadna niedogodność.

sudo sujest nieco zbędny. Nie ma potrzeby używania dwóch programów, które mają umożliwić uruchamianie programów jako inny użytkownik, jeden wystarczy. Po prostu użyj sudo -ilub sudo -s(lub sudo /bin/bashitp.), Jeśli chcesz uruchomić powłokę.

Czy coś przeoczyłem? Czy świat wykonuje zezwolenie na su tylko z powodów historycznych?

Patrz wyżej. Cóż, nie wszystkie systemy mają sudoalternatywę, nie jestem pewien, czy uważasz to za historyczne.

Czy są jakieś wady usuwania tego uprawnienia, którego jeszcze nie spotkałem?

Nie bardzo, o ile mi wiadomo. Myślę, że niektóre systemy zostały suustawione tak, aby tylko członkowie określonej grupy („ wheel”) mogli to uruchomić. Możesz zrobić to samo, sudojeśli chcesz ( chown root.sudousers /usr/bin/sudo && chmod 4710 /usr/bin/sudo).

Lub możesz po prostu usunąć jeden lub oba programy, jeśli ich nie potrzebujesz. Chociaż w Debianie sujest dostarczany z loginpakietem, więc prawdopodobnie nie jest dobrym pomysłem usunięcie pakietu jako całości. (A łączenie w pary logini sutakie razem wydaje się nieco historyczne.)

Masz już dobre odpowiedzi, ale jest jedna część Twojego postu, której nie dotyczą.

O ile wiem, światowe uprawnienia do wykonywania / usr / bin / su to jedyna droga dla użytkowników próbujących uzyskać root na moim serwerze.

To niebezpieczne założenie. Jeśli ustawiłeś dobre hasło do roota, w większości przypadków znacznie bardziej prawdopodobne jest, że pomyślne zwiększenie uprawnień nastąpi z powodu wykorzystania błędu w jądrze lub pliku binarnego setuid (oczywiście możesz również usunąć setuid nieco z nich, ale passwdjest setuid, a jeśli chcesz wysokiego bezpieczeństwa, powinieneś również zaoferować to swoim użytkownikom, a odmowa im zmiany hasła nie jest z tym zgodna).

su musi być wykonywalny na całym świecie, aby każdy mógł go uruchomić. W wielu systemach można go zmienić na innego użytkownika, podając jego hasło.

Jeśli obawiasz się, że ktoś brutalnie forsuje hasło roota, możesz po prostu je wyłączyć. (unieważnij skrót, aby żadne podane hasło nie było zgodne)

Nie wiem o konsensusie, ale rozważę możliwość zalogowania się jako root bezpośrednio jako problem bezpieczeństwa sam w sobie.

Pozostałe odpowiedzi są prawidłowe, mówiąc „su” pozwala zalogować się na konta inne niż root.

Jedna uwaga na temat „sudo su”. To pozwala ci zalogować się na konto roota bez znajomości hasła roota. Musisz znać hasło do konta, na którym uruchamiasz sudo, a także mieć to konto w pliku sudoers.