Почему групповой каталог с возможностью записи считается небезопасным?
В частности, почему демон libslack считает файлы, которые выполняются в каталоге с возможностью записи для группы, «небезопасными»? Если вы можете дать мне объяснение того, почему групповые каталоги, доступные для записи, считаются небезопасными, то в общем смысле это тоже было бы неплохо.
Извините, очевидно, это было слишком неясно. На странице руководства демона libslack указано:
-U, --unsafe
Разрешить чтение небезопасного файла конфигурации и выполнение небезопасного исполняемого файла. Файл конфигурации или исполняемый файл небезопасны, если они доступны для записи группой или миром или находятся в каталоге, доступном для записи группой или миром (по символическим ссылкам). Если исполняемый файл представляет собой скрипт, интерпретируемый другим исполняемым файлом, то он считается небезопасным, если интерпретатор небезопасен. Если интерпретатором является / usr / bin / env (с аргументом, который является именем команды, которое нужно искать в $ PATH), то эта команда должна быть безопасной. По умолчанию daemon (1) откажется читать небезопасный файл конфигурации или выполнять небезопасный исполняемый файл при запуске от имени пользователя root. Этот параметр отменяет это поведение и, следовательно, никогда не должен использоваться.
В конце говорится, что эта опция (небезопасная опция) никогда не должна никогда использоваться явно / предположительно из-за проблем безопасности.
Лично я не могу думать о том, что было бы небезопасно при демонизации чего-либо, находящегося в каталоге, доступном для записи в группе.
Я не понимаю, почему мой вопрос также был отложен, потому что он кажется мне довольно простым вопросом для тех, кто действительно его читает, но здесь сделана попытка записать его более четко.
Почему для файла считается небезопасным наличие в своем пути каталога, доступного для записи группой?
Для меня это более конкретно в отношении демона libslack, но я видел, как несколько других пакетов помечали одинаково сценарий также небезопасен, поэтому, если бы вы могли предоставить мне некоторую информацию о том, какого типа проблемы безопасности я мог ожидать из-за того, что я запустил - несмотря на предупреждение - демон с флагом unsafe, это было бы замечательно.
1 ответ
Из руководства sendmail/Majordomo:
2.4.1. Последствия небезопасных записей группы
Если у пользователя есть разрешение записи получить доступ к файлу псевдонимов, она должна быть доверяемым пользователем. Путем помещения записи в файл псевдонимов (такой как тот, используемый для выполнения обертки), пользователь может выполнить любую программу с полномочиями Sendmail (демон или, в более старых версиях, корне). Эта оплошность позволила бы людям удалять или изменять полномочия файлов, которые принадлежат демону (использующий
rmилиchmodкоманды в файле псевдонимов). В некоторой степени этой возможности избегают при помощи smrsh; однако, нужно все еще быть осторожным относительно того, какие файлы находятся в/etc/smrsh/ каталог.Другая важная проблема безопасности - то, что пользователь, который может получить доступ к файлу псевдонимов, может добавить или записать в файлы, которые принадлежат демону при помощи перенаправления файла (
a >>или>вместоa |). Несмотря на это, этому нарушению также можно противостоять путем добавления строки кsendmail.cfограничение файла, во что могут быть записаны файлы через файл псевдонимов.
<..>
В случае
includeили.forwardфайлы, команды или перенаправления выполняются как пользователь, который владеет файлом. Поэтому, если файл является перезаписываемой группой, член группы может выполнить команды как пользователь, который владеет файлом. Другими словами, любой пользователь в группе мог выполнить команды как тот пользователь. Однако, так как пользователь создается без оболочки, команды или перенаправления не будут обработаны вincludeфайлы принадлежат тому пользователю.4.2. Последствия небезопасной группы перезаписываемые пути к каталогам
Если пользователь сделал, чтобы группа записала разрешение в каталог, например
/etc/, пользователь мог просто переместить любой файл и создать новый в его месте. Нападение могло бы пройти примерно так
[user@system etc]$ mv aliases ...
[user@system etc]$ vi aliases
Пользователь может затем сделать ее собственные псевдонимы! Это нападение, однако, могло быть предотвращено проверкой безопасности Sendmail небезопасную группу перезаписываемые пути. Такое нападение также работало бы с
includeи.forwardфайлы, имеющие небезопасные пути.
Это руководство объясняет это вполне прилично, и та же логика относится ко многим другим частям программного обеспечения: ум, что Вы используете многопользовательскую систему даже при том, что Вы могли бы быть единственным пользователем той системы. И в многопользовательской системе пользователь должен быть защищен от других пользователей.