☰

Почему непривилегированный пользователь не может изменить владельца файла?

tag-icon • tag-icon linux chown
Почему непривилегированный пользователь не может изменить владельца файла?

Из chown(2):

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

В чем причина этого ограничения? Почему непривилегированный пользователь не может изменить владельца файла, которым он владеет (т. е. нет /etc/shadow)?

$ touch blah
$ chown root:root blah
chown: changing ownership of `blah': Operation not permitted

решение1

Позволяя пользователям «раздавать» файлы, вы нарушаете различные функции ОС. Такие как:

Taking up another user's disk quota.
Impersonating another user (or even root) via setuid.
Having insufficient privileges to undo a mistaken chown.
Making it appear that someone else had created a given file.
Setting up cron jobs to run on other user's accounts.
And many more...

решение2

Это просто личный выбор разработчиков Linux — не допускать этого — все эти псевдосоображения безопасности,данный, являются ложными, поскольку существуют системы Unix, которые это допускают.

Я думаю, эта функциональность зависит от того, соответствует ли поведение вашей Unix «System-V» (AT&T) или Unix Беркли (BSD)...

Что касается других упомянутых проблем безопасности:

  • Выдача себя за другого пользователя (или даже root) через setuid.

    Не проблема: смена «владельца» очищает все биты «setXid» (U/G)

  • Недостаточно привилегий для отмены ошибочного chown

    На самом деле это не «угроза безопасности», НО она может быть в системах, которые позволяют менять пользователя. Вы можете вернуть его обратно, если он находится в каталоге, которым вы владеете. В противном случае: «будьте осторожны»!

  • Создается впечатление, что данный файл создал кто-то другой.

    Он все еще будет находиться в каталоге, доступном для записи для вас. То есть вы не сможете переместить его в их домашний каталог, если только он не открыт для записи для вашей группы или всех (или конкретно для вас, если доступны списки контроля доступа).

  • Настройка заданий cron для запуска на учетных записях других пользователей.

    Опять же, это не сработает, так как crondirs принадлежат пользователю и даже не настроены на это.удобочитаемыйдругими пользователями, не говоря уже о возможности записи.

  • если бы кто угодно мог изменить владельца, то кто угодно мог бы изменить разрешения, чтобы получить доступ к любому файлу в системе.

    Нет: только если пользователь «владеет» каталогом, содержащим этот файл. То есть я могу дать файл с именем «passwd» root, но я не смогу переместить его в /etc/, если у меня нет прав на запись в /etc/.

  • квоты

    Потенциально обоснованный момент —ЕСЛИвы используете квоты, но кажется, что это будет легко обнаружить, если вы суммируете дисковое пространство по home-dir; Единственная проблема будет в каталогах, которые доступны для записи нескольким пользователям. В этом случае, возможно, следует обратиться к владельцу этого 'dir'. ЭтоМОЖЕТможет быть, в тех системах, которые поддерживают «раздачу» файлов, вы можете делать это только в каталогах, которыми вы «владеете», но прошло ДАВНО много времени с тех пор, как я работал в системе, которая это позволяла, поэтому я не помню точных ограничений.

Кажется, я припоминаю, что существовал какой-то «компромисс» за разрешение «раздачи файлов»... например, в системах, где это разрешено, что-то еще не разрешено, что разрешено в Linux, но не могу вспомнить, что именно...

Я бы сказал, что приведенный выше «ответ» следует снять с отметки как ответ, поскольку это НЕ настоящий ответ. Это скорее дизайнерское решение — я просто не знаю, в чем заключался компромисс(ы).

Возможно, существуют проблемы безопасности, не упомянутые выше, которые могли бы вызывать обоснованные опасения, но те, что перечислены выше, не являются обоснованными.

На мой взгляд, это должно быть системное «значение» в «/proc», но, в общем и целом, я думаю, что большинству людей это не так уж и важно.

Если бы в этом была острая необходимость, можно было бы усилить безопасность «chown» и модифицировать ее, чтобы разрешить ее использование, а затем настроить с помощью setuid «root», чтобы разрешить реализацию такой политики.

решение3

Ну, если бы кто угодно мог изменить владельца, то кто угодно мог бы изменить разрешения, чтобы получить доступ к любому файлу в системе. Это плохо не только с точки зрения вредоносного ПО (sudo не требуется), но и с точки зрения системного администратора. Если бы кто угодно из пользователей мог изменить любой из файлов, то разрешения на файлы бесполезны.

решение4

Потому что тогда пользователь может обойти квоты файловой системы. Если у меня квота 100 МБ, а у вас квота 100 МБ, я могу загрузить 100 МБ, chmod a+r, chown вам, а затем загрузить еще 100 МБ.

Связанный контент