Protože sudo umožňuje mnohem jemnější ovládání než "přihlaste se jako root a pak si dělejte, co chcete." Můžete například nakonfigurovat sudo takže někteří uživatelé mohou spouštět pouze určité příkazy (jako obalové skripty nebo "přijatelné" binární soubory). Obáváte se, že trojský kůň ohrozí počítač jednoho uživatele, ale sudo byl vytvořen, aby umožňoval protokolování a řízení přístupu na serveru, který spravuje více lidí.
Samozřejmě v systému pro jednoho uživatele jsou důležitými soubory soubory uživatele, a jakmile získáte přístup k uživatelskému účtu, již k těmto souborům máte přístup , takže získání hesla už není ani tak důležité. I když je vaším cílem heslo (řekněme, že útočíte na někoho, kdo znovu používá hesla), existuje spousta způsobů, jak ho získat, aniž byste museli používat sudo; nedávno jsem se například setkal se 2 nainstalovanými programy, které zaznamenávají hesla nebo chyby v heslech v prostém textu.
A konečně, je vhodné nespouštět jako root, kdykoli je to možné, protože následky nesprávného zadání příkazu (rm_-rf_._/ je zřejmým příkladem) nejsou tak závažné. Vyžaduje další krok zápisu sudo na začátku příkazu, na rozdíl od toho, že „zapomenete, že jste přihlášeni jako root a uděláte něco destruktivního“, můžete předejít některým jednoduchým, ale vážným chybám.
Pro sudo existují platná pohodlná použití, ale protože jsou již dostatečně vysvětlena v jiných příspěvcích, nebudu je zde moc rozvádět. Uvedu vás však na sudoers(5) , což je konfigurační soubor sudo. Ukazuje některé z rozsáhlé konfigurace možné pomocí sudo. Vysvětlím, kdy a proč byste neměli používat sudo k povýšení z vašeho běžného uživatele na root z čistě bezpečnostních důvodů, kromě pohodlí.
Krátká odpověď: Neexistuje žádný způsob, jak bezpečně používat sudo, pokud může být ohrožen váš běžný uživatel. Používejte jej pouze pro pohodlí, nikoli pro bezpečnost. Totéž platí pro su a všechny ostatní programy, které lze použít k povýšení vašeho běžného uživatele na privilegovanějšího.
Dlouhá odpověď: Není pravda, že použití úplné cesty pro sudo vás ochrání před škodlivým prostředím. To je běžné nedorozumění. Funkce bash může dokonce unést názvy obsahující / na začátku. Zkuste spustit následující:
$ echo $SHELL
/bin/bash
$ function /usr/bin/sudo { echo "Trust me, now put in your password:"; }
$ /usr/bin/sudo id
Trust me, now put in your password:
Musíte použijte pouze volbu 1, neboli přihlášení pomocí agetty nebo přihlášení na jiném tty (všimněte si, že v některých distribucích je tty1 místo, kde běží Xorg, jako je Fedora. Ve většině distribucí je však tty1 náhradní tty a Xorg běží na tty7) . Nicméně , musíte si být vědomi toho, že malware může unést ctrl +alt +f1 a zobrazí vám falešnou obrazovku, takže musíte použít kombinaci klíče Secure Attention (SAK, což je alt +sysrq +k na systémech Linux), který zabije všechny procesy v tomto tty. To zabije jakoukoli falešnou přihlašovací obrazovku a přivede vás pouze na tu skutečnou. Pokud neexistují žádné falešné přihlašovací obrazovky, které se snaží ukrást vaše root heslo (což je doufejme tento případ), pak to jednoduše způsobí restart agetty, což by se nemělo objevit jako nic jiného než blikající výzva k přihlášení. Na některých systémech je mnoho funkcí SysRq zakázáno, včetně SAK. Všechny je můžete dočasně povolit zapsáním celého čísla 1 až /proc/sys/kernel/sysrq . Hodnota /proc/sys/kernel/sysrq je bitmapa, takže se podívejte na to, co to aktuálně je, a spočítejte si, na co ji potřebujete převést, abyste přidali podporu SAK, než ji učiníte trvalou v /etc/sysctl.conf . Nastavit na 1 navždy může být špatný nápad (nechcete, aby mohl altovat jen kdokoli +sysrq +e zabít xscreensaver, že?).
Myšlenka, že můžete chránit svého běžného uživatele a bezpečně používat sudo nebo su, je velmi nebezpečný nápad. I kdyby to bylo možné, existuje nespočet způsobů, jak unést vaši běžeckou relaci, například LD_PRELOAD , což je proměnná prostředí, která ukazuje na sdílený objekt (knihovnu), který bude násilně načten programem, aby změnil své chování. I když to nefunguje na programech setuid, jako je su a sudo, funguje to na bash a všechny ostatní shelly, které provádějí su a sudo a jsou těmi, kdo vidí všechny vaše úhozy. LD_PRELOAD není jedinou proměnnou, která může unést programy běžící jako váš uživatel. LD_LIBRARY_PATH může říci programu, aby místo vašich systémových knihoven používal škodlivé knihovny. Existuje mnohem více proměnných prostředí, které lze použít ke změně chování spuštěných programů různými způsoby. V zásadě platí, že pokud mohou být ohroženy vaše proměnné prostředí, může být ohrožen váš uživatel a všechny stisknuté klávesy zadané jako tento uživatel.
Pokud by to nestačilo, ve většině distribucí může váš uživatel použít ptrace() s GETREGS nebo PEEKTEXT/PEEKDATA možnosti pro zobrazení celé paměti procesů spuštěných jako stejný uživatel (jako je proces bash, který za vás spouští su nebo sudo). Pokud používáte distribuci, která to zakazuje (např. pomocí Yama LSM), proces stále může být schopen číst a zapisovat do paměti vašeho bash procesu pomocí process_vm_readv() a process_vm_writev() respektive. Na některých jádrech můžete také zapisovat přímo do paměti přes /proc/pid/mem , pokud je proces, který do něj zapisuje, stejný uživatel. V linuxovém jádře existuje nespočet bezpečnostních kontrol, aby se zajistilo, že se procesy nemohou navzájem rušit. Všechny však zahrnují inter -ochrana uživatele, nikoli intra - ochrana uživatele. Linuxové jádro předpokládá, že každé jednotlivé věci provedené jako uživatel A důvěřuje uživatel A, takže pokud chcete rootovat jako uživatel A, musí být root stejně důvěryhodný jako tento uživatel.
Než se vůbec dostanu ke Xorg, dovolte mi začít tím, že Xorg neposkytuje žádnou ochranu před keyloggery. To znamená, že pokud použijete sudo nebo su v tty se spuštěným Xorg, všechny procesy běžící pod stejným uživatelem budou moci čichat (a vkládat) stisknuté klávesy. Je to proto, že model zabezpečení protokolu X11 předpokládá, že cokoli s přístupem k souboru cookie X11 je důvěryhodné a že tento soubor cookie je přístupný všemu, co běží pod vaším uživatelem. Je to základní omezení protokolu X11, zakořeněné tak hluboko, jako je koncept UID v Linuxu. Neexistuje žádné nastavení nebo funkce, která by to zakázala. To znamená, že cokoli, co napíšete v relaci Xorg, včetně napsání do su nebo sudo (nebo frontendů jako gksu, gksudo, kdesu, kdesudo, pinentry atd.), může být vyčmucháno čímkoli, co běží jako stejný uživatel, takže váš prohlížeč, vaše hry , váš přehrávač videa a samozřejmě vše, co je vytvořeno vaším .bashrc. Můžete to sami vyzkoušet spuštěním následujícího v jednom terminálu a poté přesunem na jiný terminál a spuštěním příkazu pomocí sudo.
$ xinput list
Virtual core pointer id=2 [master pointer (3)]
↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
↳ ETPS/2 Elantech Touchpad id=13 [slave pointer (2)]
Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=8 [slave keyboard (3)]
↳ USB Camera id=10 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=12 [slave keyboard (3)]
↳ Video Bus id=7 [slave keyboard (3)]
↳ Sleep Button id=9 [slave keyboard (3)]
↳ Asus WMI hotkeys id=11 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
$ xinput test 12 # replace 12 with the id number of your keyboard
key press 45
key press 44
key release 40
key press 41
key release 45
key release 44
key release 41
key press 31
^C
Všimněte si, že pokud tento konkrétní test pro vás nefunguje, znamená to, že nemáte XTEST rozšíření aktivní. I když není aktivní, je stále možné zaznamenávat události klávesnice pomocí XQueryKeymap() . Ponaučení, které byste si měli vzít, je, že v podstatě žádný způsob neexistuje pro bezpečné zadání hesla pomocí su nebo sudo prostřednictvím kompromitovaného uživatele. Bezpodmínečně musíte přejít na nový tty a používat SAK, poté se přihlásit přímo jako root.
Kromě toho, co zmiňují ostatní uživatelé, sudo také zachovává původní identitu uživatele, který provádí příkaz. To znamená, že můžete sledovat, jaké uživatelské jméno provedlo příkaz. Pokud používáte root ve víceuživatelském prostředí, nebudete moci sledovat provádění příkazu pro jednoho uživatele, protože uid bude 0.