Как работают внутренние органы sudo?

Как sudoработает внутренне? Как это возможно, что он может стать пользователем root без пароля root, в отличие от su? Какие системные вызовы и т. Д. Участвуют в процессе? Разве это не зияющая дыра в безопасности в Linux (например, почему я не мог скомпилировать исправленную версию, sudoкоторая просто делала то, что делал обычный пользователь sudo, но не запрашивала пароль непривилегированного пользователя)?

Я прочитал логин и су внутренности . Я также прочитал, как sudo предназначен для использования? но несмотря на название, они в основном имеют дело с различиями между suи sudo.

Если вы посмотрите на исполняемый файл sudo:

$ which sudo
/usr/bin/sudo
$ ls -la /usr/bin/sudo
---s--x--x 2 root root 208808 Jun  3  2011 /usr/bin/sudo

Вы заметите, что он несет биты разрешения ---s--x--x. Они могут быть разбиты следующим образом:

-|--s|--x|--x
-      - first dash denotes if a directory or a file ("d" = dir, "-" = file)  
--s    - only the setuid bit is enabled for user who owns file
--x    - only the group execute bit is enabled
--x    - only the other execute bit is enabled

Поэтому, когда в программе активирован бит setuid (также называемый SUID), это означает, что когда кто-то запускает эту программу, она запускается с учетными данными пользователя, которому принадлежит файл, иначе. корень в этом случае.

пример

Если я запускаю следующую команду от имени пользователя saml:

$ whoami
saml

$ sudo su -
[sudo] password for saml: 

Вы заметите, что выполнение sudoфактически выполняется от имени пользователя root:

$ ps -eaf|grep sudo
root     20399  2353  0 05:07 pts/13   00:00:00 sudo su -

механизм setuid

Если вам интересно, как работает SUID, взгляните на man setuid. Вот выдержка из справочной страницы, которая объясняет это лучше, чем я мог:

setuid () устанавливает эффективный идентификатор пользователя вызывающего процесса. Если эффективный UID вызывающего абонента является пользователем root, также устанавливаются реальный UID и сохраненный set-user-ID. В Linux setuid () реализован как версия POSIX с функцией _POSIX_SAVED_IDS. Это позволяет программе set-user-ID (кроме root) отбросить все свои пользовательские привилегии, выполнить некоторую непривилегированную работу и затем повторно безопасно включить исходный эффективный ID пользователя.

Если пользователь является пользователем root или программа настроена как user-ID-root, необходимо соблюдать особую осторожность. Функция setuid () проверяет эффективный идентификатор пользователя вызывающей стороны, и, если это суперпользователь, все идентификаторы пользователя, связанные с процессом, устанавливаются в uid. После того, как это произошло, программа не может восстановить привилегии root.

Ключевой концепцией здесь является то, что программы имеют реальный идентификатор пользователя (UID) и эффективный (EUID). Setuid устанавливает эффективный идентификатор пользователя (EUID), когда этот бит включен.

Таким образом, с точки зрения ядра известно, что в нашем примере samlон все еще является первоначальным владельцем (UID), но EUID был установлен с тем, кто является владельцем исполняемого файла.

setgid

Я должен также упомянуть, что когда мы разбиваем разрешения для команды sudo, вторая группа битов предназначена для групповых разрешений. Групповые биты также имеют нечто похожее на setuid, называемое set group id (aka. Setgid, SGID). Это делает то же самое, что и SUID, за исключением того, что он запускает процесс с учетными данными группы вместо учетных данных владельца.

Рекомендации

• setuid википедия
• man-страница setuid

Настоящий sudoбинарный файл - это setuid root , и вы не можете просто создать файлы, которые установлены таким образом.

setuid и setgid (сокращение от «установить идентификатор пользователя при выполнении» и «установить идентификатор группы при выполнении» соответственно) [1] - это флаги прав доступа Unix, которые позволяют пользователям запускать исполняемый файл с разрешениями владельца или группы исполняемого файла соответственно и изменить поведение в каталогах.

Чтобы ответить на часть о системных вызовах, которых, кажется, никто не трогал, одним из важных системных вызовов является либо setresuid (), либо setresgid (). Я уверен, что есть и другие, но эти 2 кажутся довольно специфичными для setuid / sudo.