Есть ли идеальный способ ограничить доступ администраторов сервера к тому, что они могут и не могут делать с помощью sudo? Я хотел бы иметь уровни доступа от базовых действий командной строки до более продвинутых возможностей, таких как управление службами. Я также не хочу, чтобы у них была возможность касаться root или редактировать журналы.
Я использую CentOS 6 с CPanel на ящиках.
Вы можете использовать псевдонимы команд, чтобы разрешить или запретить такие действия, например:
Cmnd_Alias OPS = /usr/sbin/shutdown,\
/usr/sbin/reboot,\
/bin/su,\
/bin/sh,\
/bin/csh
%dev ALL = (ALL:ALL) ALL, !OPS
В принципе, %dev означает, что любой член группы разработчиков может делать что угодно, как и любой пользователь, ЗА ИСКЛЮЧЕНИЕМ OPS который предоставляет список команд, которые вы не хотите запускать как sudo.
В качестве альтернативы вы можете создать свой собственный Cmnd_Alias и сделать %dev ALL=OPS разрешить использование только перечисленных операций.
Кроме sudo, вы можете писать сценарии, чтобы делать что-то с установленным битом suid (не обязательно suid root, возможно suid www-data или даже suid nobody) и набором битов выполнения группы, и позволять людям запускать его, добавляя их в соответствующую группу, которая владеет рассматриваемый сценарий.
sudo лучше, потому что он оставляет подробный контрольный след и может быть довольно гибким, хотя sudoers(5) man-страница довольно недружелюбна к людям и полна спагетти Бэкуса-Наура. И sudo имеет тенденцию вызывать и прекращать работу над любой синтаксической ошибкой в / etc / sudoers, поэтому вам лучше установить себе настоящий пароль root на время, которое вы настроили sudoers файл, или вы можете оказаться заблокированным из-за сломанной sudo.
sudo или не sudo, будьте очень осторожны при разработке сценариев, анализе аргументов командной строки, записи в файлы, управляемые администратором.
Один пример, давайте представим, что у вас есть сценарий, который запускается под привилегированной учетной записью (root или что-то еще), и, кстати, он записывает с усечением (>) в файл, который ваш администратор может заменить символической ссылкой, указывающей на то место, о котором вы никогда не думали .
Другой пример: редактирование / etc / network / interfaces (или его аналога в вашем дистрибутиве) с последующим запуском интерфейса может показаться невинным, но есть сценарии pre / post-up / down, которые вызываются как root. Ой.
Вы можете определить отдельные разрешенные команды sudo для каждого пользователя. Например, вместо того, чтобы давать им все команды, мы можем дать определенному пользователю под названием testing разрешение на перезапуск веб-сервера с помощью sudo:
testing ALL=/etc/init.d/httpd restart
(это должно быть в вашем файле sudoers)