У меня есть программа под названием foo, для выполнения которой требуются привилегии root. foo должен быть запущен любым пользователем и может располагаться по любому пути. Причина, по которой эта программа может находиться по любому пути, заключается в том, что наша компания разрабатывает программу foo, и каждый пользователь может иметь личную версию программы в каком-либо личном каталоге, пока он работает над ней.
У меня такой вопрос: как с этим справиться наиболее безопасно? Я изучал файл sudoers и у меня в основном 2 идеи.
1.) Перечислите все пути, по которым программа может находиться в файле sudoers. Это проблематично, потому что это требует частого редактирования списка sudoers, а также представляет угрозу безопасности, поскольку пользователи без полномочий root будут владеть своей индивидуальной копией foo и могут скопировать некоторую системную программу поверх foo, а затем использовать ее как root.
2.) Напишите сценарий с именем start_foo, который выполняет некоторую проверку ввода для переданной программы, такую как размер и имя, а затем запускает переданный в foo. start_foo может находиться в / usr / bin и принадлежать пользователю root, но может быть запущен кем угодно. Эта опция по-прежнему включает в себя дыру в безопасности, заключающуюся в возможности перезаписать пользовательскую программу foo другой программой, требующей root, но, надеюсь, проверка размера позволит выявить некоторые вредоносные случаи.
Есть ли «канонический» способ решить эту проблему, которую я не нашел или не придумал? Если нет, то какое из вышеперечисленных или, возможно, другое решение является лучшим способом решения проблемы?
Спасибо!
Самый безопасный способ справиться с этим, вероятно, - предоставить каждому из ваших разработчиков собственную небольшую среду разработки / тестирования, возможно, виртуальную машину. Таким образом, они могут сломать только свой собственный экземпляр разработки.
Очевидным и наиболее безопасным решением было бы создание нового привилегированного приложения-демона, food, который обрабатывает ваши foo приложение должно работать как root, а затем foo приложение общается с food используя, например. сокеты (Unix, TCP). Если ваш foo приложение будет скомпрометировано, злоумышленник сможет общаться только с food, который будет иметь ограниченный набор команд.
Если вы доверяете своим коллегам, вы можете добавить каждого из них в unix-группу foodevel, используйте решение 2), а затем разрешите выполнение только foo программы, если они принадлежат этой группе. Лицо, принадлежащее к определенной группе, может выдать chgrp команда над файлами, другие люди не смогут.
Кроме того, вы можете проверить решение байта sUID вместо того, чтобы зависеть от sudo. Это может не поддерживаться всеми языками программирования, и вам нужно немного знать об эффективных разрешениях (см. man seteuid).
Может быть, использовать chroot jail какой-то. Возможно создание их на лету по мере необходимости с различными файлами, которые необходимо приложению для запуска.
Это представляет огромную проблему, потому что пользователь может ИЗМЕНИТЬ сценарий в любое время. Даже если файл доступен только для чтения, они будут иметь права записи в каталог, в котором он находится.
По этой причине вам нужно, чтобы сценарий root-priv находился где-то под вашим контролем.
Вы можете сделать что-нибудь вроде
/ home / central / [имя сценария] <---- только корневой каталог, доступный для записи, доступен для чтения всем. Это тот, к которому вы можете предоставить доступ sudo
Тогда / home / [anyuser] / scriptname <--- не доступ sudo
А имя сценария - это оболочка для / home / central / [имя сценария]
Так было бы лучше и посильнее
И / home / [anyuser] / scriptname будет что-то вроде
#!/bin/bash
/home/central/[scriptname] $@ # pass all arguments