Флаги прав доступа 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]