Как работает механизм set-user-ID в Unix?

Кто-нибудь может объяснить механизм set-user-ID в Unix? Каково было обоснование этого дизайнерского решения? Чем он отличается от эффективного идентификатора пользователя?

Возможно, вы знаете обычные разрешения на чтение, запись и выполнение для файлов в Unix.

Однако во многих приложениях этот тип структуры разрешений - например, предоставление заданному пользователю либо полного разрешения на чтение данного файла, либо вообще никакого разрешения на чтение файла - слишком грубый. По этой причине в Unix есть еще один бит разрешения - set-user-IDбит. Если этот бит установлен для исполняемого файла, то всякий раз, когда пользователь, кроме владельца, исполняет файл, этот пользователь получает все привилегии владельца файла на чтение / запись / выполнение при доступе к любому из других файлов владельца!

Чтобы установить бит set-user-ID для файла, введите

 chmod u+s filename

Убедитесь, что вы также установили для группы другое разрешение на выполнение; было бы неплохо иметь разрешение на чтение для других групп. Все это можно сделать с помощью одного заявления

 chmod 4755 filename

Он также называется сохраненным UID. Файл, который запускается с включенным битом Set-UID, сохраненный UID будет UID владельца файла. В противном случае сохраненный UID будет настоящим UID.

Что такое эффективный UID?

Этот UID используется для оценки привилегий процесса для выполнения определенного действия. EUID может быть изменен на Real UID или UID суперпользователя, если EUID! = 0. Если EUID = 0, его можно изменить на что угодно.

пример

Примером такой программы является passwd. Если вы перечислите его полностью, вы увидите, что он имеет бит Set-UID, а его владельцем является «root». Когда запускается обычный пользователь, скажем «mtk» passwd, он начинается с:

Real-UID = mtk  
Effective-UID = mtk  
Saved-UID = root

Ссылочная ссылка 1
Ссылочная ссылка 2

man credentialsявляется хорошим источником информации в этом случае. Смотрите также этот вопрос на SO . Историческое объяснение смотрите в этом заархивированном посте .

Вместо того, чтобы называть механизмом «установить UID» и «эффективный UID», должна быть названа вся концепция UID. Обоснованием существования различных UID являются различные проблемы с разделением привилегий. Даже обычные (непривилегированные) пользователи иногда должны делать вещи (доступ к ресурсам), которые могут делать только привилегированные пользователи. Для этого легко, программы могут изменить свои UID. Есть 3 типа этих:

• реальный UID - UID, которому принадлежит процесс

• эффективный UID - UID, под которым в настоящий момент выполняется процесс - определяет реальные возможности процесса в любой конкретный момент. Это также то, что psпоказывает вам в поле USER.

• UID сохраненного набора - заполнитель, используемый для переключения между реальным и эффективным UID

Необходимость последнего возникает из-за того, что обычные пользователи могут переключаться только между этими тремя и ничем иным, и программе setuid обычно нужно каким-то образом знать, кто был пользователем, который ее загрузил (плюс реальный UID не должен изменяться, поскольку это создало бы еще больший беспорядок).

Расширение МТК является хорошим.

passwdПримером может служить одна из привилегий - PASSWD всегда работает как корень , так как он должен изменить файлы , которые только корневая разрешено изменять. Это делает важным, чтобы исполняемый файл passwd не был подвержен переполнению буфера и т. Д., Чтобы умный обычный пользователь мог использовать его для тех целей, для которых он не предназначен.

Другое обоснование заключается в том, чтобы защитить пользователя таким же образом, каким вы могли бы воспользоваться, suесли вы вошли в систему как пользователь root, чтобы уменьшить или ограничить ваши привилегии для определенных задач, а не наращивать их. Например, если у меня есть разрешение на запуск службы демона, которая не требует доступа к моим материалам и имеет свой собственный материал, который является всем необходимым (например, регистратор), запуск suid будет означать, что он имеет доступ только к этому материалу. и не мое или кто-либо еще.

Обратите внимание, что можно установить uid программным способом, даже если бит suid не установлен в исполняемом файле , однако это не будет работать для эскалации. То есть, если вы обычный пользователь и пишете программу, которая устанавливает uid в какой-то момент, эта программа не может переключиться на root. Я думаю, что Apache работает таким образом. Обычно он запускается пользователем root и имеет один процесс, который затем разветвляет потомков, которые переключают uid на непривилегированного пользователя (например, «httpd»). Эти дочерние процессы - это то, что работает реальный веб-сервер.