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

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

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

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

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

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

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

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

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

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

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