Почему привилегированные пользователи должны устанавливать setgid () для дополнительных групп?

Различные set*gid()системные вызовы требуют привилегий для изменения групп, за исключением очень немногих случаев. Изменение основной группы на одну из дополнительных групп процессов, по-видимому, не является одной из них, а это означает, что, например, командам newgrp/ sgнеобходимо повысить привилегии для переключения основной группы.

Есть ли причина, по которой setgid()/ setegid()/ setregid()/ setfsgid()не разрешаем переходить на дополнительную группу без привилегий? Если так, то в чем причина?

security group system-calls

— Уильям Хэй
источник

Также не уверен. Обратите внимание, что вы можете chgrp файл в одну из ваших дополнительных групп, поэтому, если у вас есть доступ на запись в область без noexec, nosuid, вы можете обойти это ограничение (создав копию /usr/bin/envс разрешением setgid).

— Стефан Шазелас

Команда newwrp уже делает это для меня AFAICT, но порождение внешней программы не всегда то, что кто-то хочет сделать.

— Уильям Хэй,

Обратите внимание, что это newgrp/sgотносится к базе данных учетных записей, а не к списку дополнительных групп процесса.

— Стефан Шазелас

Если ваш gid также отсутствует в вашем списке дополнительных идентификаторов, то разрешение setgid()позволит вам покинуть членство в группе (что может быть проблемой безопасности), но с другой стороны вы также можете сделать это с тем же приемом setgid, что и выше, и ваш гид обычно также находится в вашем дополнительном списке ( initgroups(3)принимает аргумент гид только для этого).

— Стефан Шазелас

Ответы:

Конечно, основная загадка здесь состоит в том, что проверки разрешений файловой системы основаны на комбинации (эффективного UID и) эффективного GID и дополнительных GID. Таким образом, с точки зрения проверки прав доступа к файлам эффективный GID эквивалентен дополнительным GID, что приводит к вопросу OP. (Попутно: если мы говорим о Linux, то в действительности при проверке разрешений файловой системы используются именно UID / GID файловой системы, а не эффективные UID и GID, но первые идентификаторы почти всегда имеют те же значения, что и последние идентификаторы. )

Таким образом, должны быть некоторые случаи, когда реальные / эффективные / сохраненные установленные GID не эквивалентны дополнительным GID. (Я группирую GID реального / эффективного / сохраненного набора вместе, потому что обычные правила разрешений set * gid () говорят, что непривилегированный процесс может изменить любой из этих GID на то же значение, что и один из двух других.)

И действительно, есть несколько таких случаев. access (2) выполняет свои проверки на основе реального идентификатора пользователя процесса и идентификатора группы. Если непривилегированный пользователь мог изменить действительный идентификатор группы таким же, как один из дополнительных GID, который не является действующим или сохраненным GID набора, тогда можно было бы манипулировать поведением доступа (2).

Есть и другие подобные случаи. См. Страницу руководства Linux mkdir (2) для примера. В зависимости от того, установлен ли бит режима set-GID в родительском каталоге, новый файл, созданный в каталоге, получает свою групповую собственность от действующего GID процесса создания. Опять же, если непривилегированный процесс может изменить свой эффективный GID таким же, как один из его дополнительных GID, он может неожиданно манипулировать владением группой новыми файлами. Аналогичные комментарии применимы для mknod (2) и вызовов System V IPC semget (2), shmget (2) и msgget (2).

Существуют также некоторые специфичные для Linux случаи, когда реальные / эффективные / сохраненные установленные GID не эквивалентны дополнительным GID. Смотрите, например, process_vm_readv (2) и prlimit (2).

— холодный морской тропический воздух
источник

Примечание: @mtk является автором интерфейса программирования Linux .

— Стефан Шазелас

Эффективный gid определяет групповое владение новыми файлами. Но затем вы можете поменять эту группу на один из ваших дополнительных гидов (а также дать бит setgid, позволяющий вашему процессу эффективно выполнять setgid ()). Так что это похоже на слабую причину.

— Стефан Шазелас

@ StéphaneChazelas: согласен, это немного слабо. Что касается OTOH, то теперь это двухэтапный процесс, который (и я здесь расскажу) имеет потенциал для странных гонок. Но кроме этого случая есть и другие, о которых я упоминал выше. Я не знаю, какая точная причина была для этого дизайнерского решения. Возможно, это был доступ (2), так как это древняя часть API. Многие другие появились позже (или относятся к Linux) или (я полагаю) не присутствовали на BSD, когда были добавлены дополнительные GID. Или, может быть, речь шла о сохранении исторического поведения; Я вижу, вы добавили этот пункт в качестве ответа.

— MTK

Я думаю, что причина в первую очередь историческая. Дополнительные группы не были добавлены до 4.2BSD (около 1983 года). До этого у вас были только реальные и эффективные подсказки и подсказки.

Поведение для setuid / setgid было полностью симметричным и не имело оснований этого не делать. Вы бы переключали пользователя с помощью suи группировали с sg/ newgrpвсеми исполняемыми файлами setuid. Информация о членстве в группе пользователей хранится только в пользовательской базе данных, а не в атрибутах процессов.

И интерфейс setuid / setgid не изменился, когда были добавлены дополнительные гиды.

Технически теперь, если у вас есть доступ на запись в файловую систему (где выполнение и setuid / setgid не отключены), вы все равно можете установить свой действительный или реальный идентификатор пользователя для любого из ваших дополнительных гидов (без необходимости прибегать к sg/ newgrpwhich, к примеру, только позволяют перейти к группам, определенным в пользовательской базе данных, которая не обязательно совпадает со списком дополнительных данных процесса).

cp /usr/bin/env .
chgrp any-sup-group env
chmod g+s ./env

И после выполнения envваш egid переключается на any-sup-group.

— Стефан Шазелас
источник