Цель использования setuid() в SUID-программах

Сначала я обсужу бит setuid, который используется passwd и отличается от системного вызова setuid() (который passwd не использует). Возможно, в этом вопросе присутствует некоторая путаница.

Это не защита от переполнения буфера, она уязвима к таковому, или, по сути, ко всему, что позволит злоумышленнику использовать привилегированный процесс для каких-то гнусных непреднамеренных целей. Это происходит потому, что бит setuid противоположен "отбрасыванию привилегий"; он наделяет привилегиями root, но только для процесса, а не для реального пользователя. Это включает passwd.

Эта форма setuid требует, чтобы бит файловой системы setuid был установлен на исполняемом файле; passwd имеет это, потому что ему нужны привилегии для чтения и записи /etc/passwd. Однако, мы надеемся, что passwd не имеет известных уязвимостей в безопасности (например, потенциального эксплойта переполнения), которые позволили бы злонамеренному человеку заставить его делать что-то другое, кроме чтения и записи /etc/passwd (и кроме того, что делать это правильно!), поскольку он запускается от имени root, и поэтому может делать что угодно - за исключением того, что он предназначен для выполнения только одной конкретной вещи, и заставить его делать что-то еще должно (опять же, надеемся) быть невозможно.

Поэтому использование setuid в этом смысле не является защитой от чего-либо, но это часто обсуждается в связи с уязвимостями, потому что потенциальные уязвимости очень важны для исполняемых файлов setuid.

НО: бит setuid устанавливает euid, а не фактический uid, поэтому он фактически параллелен системному вызову seteuid(), а не setuid().

Существует противоположная форма "setuid", связанная с отменой привилегий, которая включает в себя фактический системный вызов setuid() и не требует бита setuid. Это когда процесс, запущенный от имени root (потому что его запустил root или sudo), меняет свой uid на менее привилегированного пользователя. Серверы и демоны часто делают это, если им нужны привилегии root при запуске (например, для открытия привилегированного порта), но не впоследствии. Таким образом, если сервер впоследствии взломают, у него не будет привилегий суперпользователя. Вы не можете вызвать setuid(0) и получить привилегии root обратно (но можете с помощью set*e*uid).