Является ли установка бита SUID / SGID в двоичном файле SVN угрозой безопасности?

Question

Я хотел бы использовать функцию обратного вызова в репозитории SVN (Unfuddle), чтобы пинговать URL на моем сервере всякий раз, когда была сделана фиксация. У меня есть скрипт PHP, принимающий сообщение и пытающийся вызвать скрипт оболочки для выполнения 'svn update'.

Проблема, с которой я сталкиваюсь, состоит в том, что Apache работает под пользователем 'www-data' и не имеет доступа к локальному репозиторию: разрешение '.svn / lock' запрещено. Я прочитал все об установке SUID / SGID в сценариях оболочки и о том, что большинство * ОС NIX просто не поддерживают его из-за рисков безопасности.

Однако я могу установить бит SUID / SGID в двоичном файле SVN, расположенном в / usr / bin / svn. Это облегчает проблему, позволяя любому пользователю вводить команды SVN в любом хранилище; не самый идеальный ...

Мой вопрос: каков наиболее логичный / разумный / безопасный способ реализации этого типа установки, и если я оставлю биты, установленные в двоичном файле svn, это открывает серьезную угрозу безопасности, которую я не могу осознать?

Извините за скучный пост; это мой первый вопрос, и я хотел быть тщательным.

Спасибо

Answer 1

Существует 2 типа решений для такого рода проблем: опрос или управление событиями.

Примером решения с опросом может быть выполнение cronjob на вашем сервере, которое обновляется каждые N минут.Это, вероятно, будет проще всего поддерживать, если это работает для вас.Вы можете обойти всю проблему с разрешениями, запустив cron из правильной учетной записи.

Решение, которое вы рассмотрели, является решением, управляемым событиями.Обычно они менее ресурсоемки, но их сложнее настроить.Другим примером решения, управляемого событиями, было бы включение www-данных в группу svn.Установите бит SGID и выберите каталог хранилища для группы svn.Это должно позволить любому в этой группе регистрироваться / выходить.

Если вам нужно ограничиться обновлением, вы можете повысить привилегии или временно сменить пользователя.Вы используете одноразовые ssh-ключи (также называемые клавишами команд) для ssh-входа как пользователь с правильными привилегиями.Затем для обновления можно использовать один ключ назначения.

Другим способом повышения привилегий является использование sudo -u [user] [command].Обновите файл /etc/sudoers, чтобы разрешить www-данным расширять / изменять пользователя на тот, который может выполнить обновление.

В любом случае я бы НЕ использовал сценарии SUID / SGID.

Answer 2

измените права доступа к вашей рабочей копии, чтобы Apache мог писать в нее.У вас есть каталог, который вы хотите изменить, вам нужны разрешения для этого.Это так просто:)

Проблема, с которой вы тогда сталкиваетесь, заключается в том, чтобы позволить любому пользователю Apache (или взломанной странице) писать по всему вашему репо, не очень хорошая вещь.Итак, вам нужно разрешить только части системы писать в нее, и лучший способ сделать это - запустить ваш php-скрипт как пользователь, уже владеющий репо.

Это легко достигается запускомскрипт php как процесс cgi или fastcgi.Вы можете указать пользователя для использования, это вовсе не обязательно должен быть www-data, хотя для этого требуется немного больше настроек, вы можете иметь лучшую управляемость событиями и безопасность, как вы, вероятно, получите.

Вот краткое объяснение phpSuexec , которое делает это.

Answer 3

Как уже сказал CodeRich, вы можете настроить задание cron для частого обновления рабочей копии (это также решение, которое я бы использовал).

Установка svn SUID / SGID - это плохо, потому что svn может записывать файлы повсюду в файловой системе (вспомните общедоступный репозиторий, содержащий файл passwd и shadow, извлеченный в ваш / etc). Вы можете использовать небольшую программу-обертку suid (которая является SUID для вашей учетной записи пользователя, а не root), которая вводит chdir в вашу рабочую копию и выполняет там svn с правильными параметрами. Вы можете посмотреть на ikiwiki , который делает это, когда используется как cgi.

Другой способ - изменить права доступа к вашей рабочей копии, чтобы пользователь www-данных мог создавать и записывать туда файлы.