Флаги прав доступа Unix и Linux setuid и setgid (сокращение от set user identity и set group identity ) [1] позволяют пользователям запускать исполняемый файл с разрешениями файловой системы владельца или группы исполняемого файла соответственно и изменять поведение в каталогах. Они часто используются, чтобы разрешить пользователям в компьютерной системе запускать программы с временно повышенными привилегиями для выполнения определенной задачи. Хотя предполагаемые привилегии идентификатора пользователя или идентификатора группы не всегда повышены, как минимум они являются конкретными.
Флаги setuidи setgidнеобходимы для задач, требующих привилегий, отличных от тех, которые обычно предоставляются пользователю, например, возможность изменять системные файлы или базы данных для изменения пароля входа. [2] Однако некоторые из задач, требующих дополнительных привилегий, могут быть неочевидны сразу, например, pingкоманда, которая должна отправлять и прослушивать управляющие пакеты на сетевом интерфейсе.
Биты setuidи setgidобычно представлены как значения 4 для setuidи 2 для setgidв старшей восьмеричной цифре режима файла. Например, 6711имеет оба бита setuidи setgid( 4 + 2 = 6 ) установленными, а также файл доступен для чтения/записи/исполнения для владельца (7) и может быть исполнен группой (первый 1) и другими (второй 1). Большинство реализаций имеют символическое представление этих битов; в предыдущем примере это могло быть u=rwx,go=x,ug+s.
Как правило, chmodне имеет рекурсивного режима, ограниченного каталогами, поэтому изменение существующего дерева каталогов необходимо выполнять вручную с помощью такой команды, как .find /path/to/directory -type d -exec chmod g+s '{}' '\'
Флаги setuidи setgidимеют разные эффекты в зависимости от того, применяются ли они к файлу, каталогу или двоичному исполняемому или недвоичному исполняемому файлу. Флаги setuidи setgidимеют эффект только на двоичные исполняемые файлы, а не на скрипты (например, Bash, Perl, Python). [3]
Когда атрибуты setuidили setgidустановлены для исполняемого файла, то любой пользователь, способный выполнить файл, автоматически запустит файл с привилегиями владельца файла (обычно root ) и/или группы файла, в зависимости от установленных флагов. [2] Это позволяет разработчику системы разрешить запуск доверенных программ, которые пользователю в противном случае не было бы разрешено выполнять. Это не всегда может быть очевидно. Например, команде ping может потребоваться доступ к сетевым привилегиям, к которым обычный пользователь не имеет доступа; поэтому ей может быть присвоен флаг setuid, чтобы гарантировать, что пользователь, которому необходимо выполнить ping другой системы, сможет это сделать, даже если его учетная запись не имеет требуемых привилегий для отправки пакетов.
В целях безопасности система обычно запрещает вызывающему пользователю каким-либо образом изменять новый процесс, например ptrace, использовать LD_LIBRARY_PATHили отправлять ему сигналы для использования повышенных привилегий, хотя сигналы с терминала по-прежнему будут приниматься.
Хотя эта setuidфункция очень полезна во многих случаях, ее неправильное использование может представлять угрозу безопасности [2], если setuidатрибут назначается исполняемым программам, которые не были тщательно спроектированы. Из-за потенциальных проблем безопасности [4] многие операционные системы игнорируют setuidатрибут при применении к исполняемым скриптам оболочки . [ необходима цитата ]
Наличие setuidисполняемых файлов объясняет, почему chrootсистемный вызов недоступен для пользователей без прав root в Unix. Подробнее см. в ограничениях .chroot
Установка setgidразрешения на каталог приводит к тому, что файлы и подкаталоги, созданные в нем, наследуют его групповое владение, а не основную группу процесса создания файла. Созданные подкаталоги также наследуют бит setgid. Политика применяется только во время создания и, таким образом, только перспективно. Каталоги и файлы, существующие на момент setgidприменения бита, не затрагиваются, как и каталоги и файлы, перемещенные в каталог, для которого установлен бит.
Таким образом, предоставляется возможность работать с файлами в группе пользователей без явной установки разрешений, но ограничивается ожиданием модели безопасности, что существующие разрешения для файлов не будут неявно изменяться.
Разрешение setuid, установленное для каталога, игнорируется в большинстве систем UNIX и Linux . [5] [ необходима цитата ] Однако FreeBSD можно настроить на интерпретацию setuidспособом, аналогичным setgid, в этом случае она принудительно назначает все файлы и подкаталоги, созданные в каталоге, владельцу этого каталога — простая форма наследования. [6] Это, как правило, не требуется в большинстве систем, производных от BSD , поскольку по умолчанию каталоги рассматриваются так, как если бы их setgidбит всегда был установлен, независимо от фактического значения. Как указано в open(2), «Когда создается новый файл, ему присваивается группа каталога, в котором он содержится». [7]
Разрешения файла можно проверить в восьмеричной и/или буквенной форме с помощью инструмента командной строки.stat
[ торвальдс ~ ] $ stat -c "%a %A" ~/test/ 1770 drwxrwx--T 4701 на исполняемый файл, принадлежащий «root» и группе «root»
Пользователь с именем 'thompson' пытается выполнить файл. Устанавливается разрешение на выполнение для всех пользователей ('1'), поэтому 'thompson' может выполнить файл. Владелец файла - 'root', и устанавливается разрешение SUID ('4'), поэтому файл выполняется как 'root'.
Причина, по которой исполняемый файл запускается от имени «root», заключается в том, что он может изменять определенные файлы, которые обычно не разрешены пользователю, не предоставляя ему при этом полного доступа root.
Использование этого по умолчанию можно увидеть в /usr/bin/passwdдвоичном файле, /usr/bin/passwdкоторый необходимо изменить /etc/passwdи /etc/shadowв котором хранятся данные учетных записей и хэши паролей для всех пользователей, и их может изменить только пользователь «root».
[ Томпсон ~ ] $ stat -c "%a %U:%G %n" /usr/bin/passwd 4701 root:root /usr/bin/passwd [ thompson ~ ] $ passwd passwd : Изменение пароля для thompsonВладельцем процесса является не пользователь, запустивший исполняемый файл, а владелец исполняемого файла.
2770 в каталоге с именем «music», принадлежащем пользователю «root» и группе «engineers»
Пользователь с именем 'torvalds', который принадлежит в первую очередь к группе 'torvalds', но во вторую очередь к группе 'engineers', создает каталог с именем 'electronic' в каталоге с именем 'music'. Групповое владение новым каталогом с именем 'electronic' наследует 'engineers'. То же самое происходит при создании нового файла с именем 'imagine.txt'
Без SGID владельцем группы нового каталога/файла была бы «torvalds», поскольку это основная группа пользователя «torvalds».
[ torvalds ~ ] $ groups torvalds torvalds : инженеры torvalds[ торвальдс ~ ] $ stat -c "%a %U:%G %n" ./music/ 2770 root:engineers ./music/ [ торвальдс ~ ] $ mkdir ./music/electronic[ торвальдс ~ ] $ stat -c "%U:%G %n" ./музыка/электроника/ торвальдс:инженеры ./музыка/электроника/ [ torvalds ~ ] $ echo 'НОВЫЙ ФАЙЛ' > ./music/imagine.txt [ торвальдс ~ ] $ stat -c "%U:%G %n" ./music/imagine.txt торвальдс:инженеры ./music/imagine.txt [ торвальдс ~ ] $ touch ~/test[ торвальдс ~ ] $ stat -c "%U:%G %n" ~/тест торвальдс:торвальдс ~/тест 1770 в каталоге с именем «videogames», принадлежащем пользователю «torvalds» и группе «engineers».
Пользователь с именем 'torvalds' создает файл с именем 'tekken' в каталоге с именем 'videogames'. Пользователь с именем 'wozniak', который также является частью группы 'engineers', пытается удалить файл с именем 'tekken', но не может, так как не является его владельцем.
Без липкого бита 'wozniak' мог бы удалить файл, потому что каталог с именем 'videogames' позволяет читать и писать 'engineers'. Использование по умолчанию можно увидеть в /tmpпапке.
[ torvalds /home/shared/ ] $ группы torvalds torvalds : инженеры torvalds[ torvalds /home/shared/ ] $ stat -c "%a %U:%G %n" ./videogames/ 1770 torvalds:engineers ./videogames/ [ torvalds /home/shared/ ] $ echo 'НОВЫЙ ФАЙЛ' > videogames/tekken [ torvalds /home/shared/ ] $ su - wozniak Пароль:[ wozniak ~/ ] $ groups wozniak wozniak : инженеры wozniak[ возняк ~/ ] $ cd /home/shared/videogames[ wozniak /home/shared/videogames/ ] $ rm tekken rm: невозможно удалить 'tekken': Операция не разрешена3171 в каталоге с именем «blog», принадлежащем группе «engineers» и пользователю «root»
Пользователь с именем 'torvalds', который в первую очередь принадлежит к группе 'torvalds', но во вторую очередь к группе 'engineers', создает файл или каталог с именем 'thoughts' внутри каталога 'blog'. Пользователь с именем 'wozniak', который также принадлежит к группе 'engineers', не может удалить, переименовать или переместить файл или каталог с именем 'thoughts', поскольку он не является владельцем и установлен липкий бит. Однако, если 'thoughts' является файлом, то 'wozniak' может его редактировать.
Окончательное решение принимается за битом sticky. Если бы бит sticky и SGID не были установлены, пользователь 'wozniak' мог бы переименовать, переместить или удалить файл с именем 'thoughts', поскольку каталог с именем 'blog' позволяет читать и писать группе, а wozniak принадлежит к группе, а umask по умолчанию 0002 позволяет группе редактировать новые файлы. Бит sticky и SGID можно объединить с чем-то вроде umask только для чтения или атрибута только для добавления.
[ torvalds /home/shared/ ] $ группы torvalds torvalds : инженеры torvalds[ torvalds /home/shared/ ] $ stat -c "%a %U:%G %n" ./blog/ 3171 root:engineers ./blog/ [ torvalds /home/shared/ ] $ echo 'НОВЫЙ ФАЙЛ' > ./blog/thoughts [ torvalds /home/shared/ ] $ su - wozniak Пароль:[ возняк ~/ ] $ cd /home/shared/blog[ wozniak /home/shared/blog/ ] $ группы wozniak wozniak : инженеры wozniak[ wozniak /home/shared/blog/ ] $ stat -c "%a %U:%G %n" ./мысли 664 torvalds:engineers ./мысли [ wozniak /home/shared/blog/ ] $ rm thoughts rm: невозможно удалить 'mysls': Операция не разрешена[ wozniak /home/shared/blog/ ] $ mv thoughts /home/wozniak/ mv: невозможно переместить «мысли» в «/home/wozniak/thoughts»: Операция не разрешена[ wozniak /home/shared/blog/ ] $ mv мысли размышления mv: невозможно переместить «мысли» в «размышления»: Операция не разрешена[ wozniak /home/shared/blog/ ] $ echo 'ПЕРЕЗАПИСАТЬ!' > мысли [ wozniak /home/shared/blog/ ] $ кошачьи мысли ПЕРЕПИШИТЕ!Разработчики тщательно проектируют и реализуют программы, которые используют этот бит в исполняемых файлах, чтобы избежать уязвимостей безопасности, включая переполнение буфера и внедрение пути. Успешные атаки с переполнением буфера на уязвимые приложения позволяют злоумышленнику выполнить произвольный код с правами эксплуатируемого процесса. В случае, если уязвимый процесс использует setuidбит для запуска как root, код будет выполнен с привилегиями root, фактически предоставляя злоумышленнику доступ root к системе, на которой запущен уязвимый процесс.
Особое значение в случае процесса setuidимеет среда процесса. Если среда не очищена должным образом привилегированным процессом, ее поведение может быть изменено непривилегированным процессом, который ее запустил. [8] Например, GNU libc в какой-то момент была уязвима для эксплойта , использующего setuidпеременную среды, которая позволяла выполнять код из ненадежных общих библиотек . [9]
Бит setuidбыл изобретен Деннисом Ритчи [10] и включен в su. [10] Его работодатель, тогда Bell Telephone Laboratories , подал заявку на патент в 1972 году; патент был выдан в 1979 году под номером патента US 4135240 «Защита содержимого файлов данных». Позднее патент был размещен в открытом доступе . [11]