Zajímalo by mě, že program SUID jako passwd používá setuid() volání funkce. Proč ruší práva uživatele root?
Proti jakým typům útoků to pomáhá? Přetečení vyrovnávací paměti?
Přijatá odpověď:
Nejprve proberu bit setuid, který passwd používá a je odlišný od setuid() systémové volání (které passwd nepoužívá). V této otázce je možná v tomto ohledu nějaký zmatek.
Není to ochrana proti přetečení vyrovnávací paměti, je to zranitelné k takovému, nebo v podstatě k čemukoli, co by útočníkovi umožnilo použít privilegovaný proces k nějakému hanebnému nezamýšlenému účelu. Je to proto, že bit setuid je opakem „odstranění oprávnění“; to uděluje oprávnění root, ale pouze pro proces a ne skutečný uživatel. To zahrnuje passwd .
Tato forma setuid vyžaduje bit setuid souborového systému nastavený na spustitelném souboru; passwd má to, protože potřebuje oprávnění ke čtení a zápisu /etc/passwd . Doufáme však, že passwd nemá žádné známé bezpečnostní chyby (např. potenciální zneužití při přetečení), které by umožnily zlovolné osobě přimět jej k něčemu jinému než ke čtení a zápisu /etc/passwd (a kromě toho, že by to dělal správně!), protože běží jako root, a proto mohl dělat cokoli – kromě toho, že je navržen tak, aby dělal pouze jednu konkrétní věc, a přimět ho, aby dělal cokoli jiného, měl by (opět doufám) nemožné.
Takže použití setuid v tomto smyslu není ochranou proti ničemu , ale často se o tom mluví v souvislosti se zranitelnostmi, protože potenciální zranitelnosti jsou velmi důležité spustitelné soubory WRT setuid.
ALE:bit setuid nastavuje euid a ne skutečné uid, takže je ve skutečnosti paralelní s seteuid() systémové volání a ne setuid() .
Existuje opačná forma „setuid“, která se týká zrušení oprávnění, což zahrnuje skutečné setuid() systémové volání a nevyžaduje setuid bit. To je, když proces běžící jako root (protože jej spustil root nebo sudo) změní své uid na méně privilegovaného uživatele. Servery a démoni to často dělají, pokud potřebují oprávnění root při spuštění (např. k otevření privilegovaného portu), ale ne následně. Tímto způsobem, pokud je server následně jackován, nemá práva superuživatele. Nemůžete volat setuid(0) a získat zpět oprávnění root (ale můžete pomocí set*e *uid).