Насколько безопасно хранить не-root-скрипты в /etc/init.d?

15

У меня есть приложение, которое работает как демон и управляется скриптом в /etc/init.d.
Иногда нам нужно изменить некоторые параметры запуска / управления этими скриптами, а затем перезапустить демон. Эти сценарии имеют разрешение на запись только для пользователя root, поэтому при редактировании этих сценариев мне нужны права root.

Я думал о том, что я должен сделать не-root-пользователя владельцем этих скриптов. Таким образом, только root и специальный пользователь могут редактировать эти скрипты.

Допустимо ли хранить некоторые файлы без полномочий root в каталогах /etc/init.d?
Или это абсурд, нарушающий естественный порядок системы?

Akaks
источник
1
плохая идея, не надо.
ChuckCottrill

Ответы:

17

Что сразу приходит на ум, так это то, что неимущий пользователь может запускать программы при загрузке с правами root , что желательно взломщикам, которые:

  • Хотите повысить привилегии других учетных записей
  • Хотите использовать свой сервер для размещения мошеннического сервиса
  • Хотите запустить IRC / Спам-ботов, если сервер перезагружается
  • Хотите проверить связь с материнским кораблем, чтобы сказать: «Я снова в сети» и, возможно, загрузить новую полезную нагрузку.
  • Хочу почистить следы
  • ... другая плохость.

Это возможно, если ваш малообеспеченный пользователь каким-то образом скомпрометирован, возможно, через другую службу (http / etc). Большинство злоумышленников быстро включат lsили findвключат / все, /etcпросто чтобы увидеть, существуют ли такие возможности, есть оболочки, написанные на разных языках, которые они используют, что делает это простым.

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

Вы определенно не хотите, чтобы это произошло, root действительно должен иметь этот скрипт инициализации. Вы можете добавить пользователя-разработчика в список sudoers, чтобы было достаточно удобно обновлять сценарий, но я бы посоветовал не разрешать доступ для записи с низким уровнем привилегий к чему-либо в init.d

Тим Пост
источник
5
tl; dr : если вы сделаете это, пользователь без полномочий root будет таким же, как пользователь root, при следующей загрузке. Вы просите, чтобы вас обстреляли.
Уоррен Янг
9

В дополнение к очень хорошим моментам, высказанным Тимом Постом, я бы добавил, что для установки, где несколько человек должны иметь возможность вносить изменения на сервер, вам следует рассмотреть возможность использования какой-либо системы управления конфигурацией.

Если вы, например, используете puppet, или chef, или cfengine, вы можете попросить соответствующих пользователей отредактировать файлы локально, а затем отправить изменения в управление конфигурацией. Как именно это настроить, конечно, будет зависеть от того, какую систему вы используете, но при правильной настройке оно будет включать в себя программное обеспечение контроля версий, позволяющее легко вернуться к более ранней версии файла конфигурации, когда (примечание: когда , а не если !) кто-то сделал ошибку. Это также облегчит вам копирование конфигурации в отдельную тестовую систему и т. Д.

Дженни Д
источник
Сохранение версий ваших сценариев и даже файлов данных конфигурации в системе управления конфигурацией / версией - отличная идея, даже без учета возможности взлома системы.
ChuckCottrill
Действительно - я использовал его для исправления ошибок на пару величин чаще, чем для исправления скомпрометированной системы.
Дженни Д
Большое спасибо . Потому что здесь в основном выделенный пользователь использует это приложение, поэтому sudo довольно хорошо работает, и это то, чем я занимался долгое время. НО Я ДЕЙСТВИТЕЛЬНО очень заинтересован системой управления версиями для конфигов. Уважаемая Дженни, не могли бы вы предоставить мне какие-либо ссылки на это ИЛИ ЛЮБОЙ ПРИМЕР !! :).
Акакс
1
Если вы не хотите использовать полный маршрут puppet / chef / cfengine и т. Д., Я бы лично использовал www.perforce.com. Мы использовали это для ~ 100 серверов за время до появления puppet, и их одной лицензии достаточно для одного сервера. Основным преимуществом является то, что вы можете извлекать файлы VC в любом месте файловой системы, а не ограничиваться одним подпутем. Другие варианты: joeyh.name/code/etckeeper или использование любого VC в сочетании со сценариями для перемещения файлов в соответствующий каталог.
Дженни Д