sudo или acl или setuid/setgid?
По какой-то причине я не очень понимаю, все хотят sudo для всех и всего. На работе у нас даже столько записей, сколько есть способов прочитать лог-файл (head/ tail / cat / more,...).
Я думаю, что sudo побеждает здесь.
Я бы предпочел использовать сочетание каталогов setgid/ setuid и добавить ACL тут и там, но мне действительно нужно знать, какие передовые практики перед запуском.
Наши серверы имеют%admin, %production, %dba, %users -ie много групп и много пользователей. Каждая служба (mysql, apache, ...) имеет свой собственный способ установки привилегий, но члены группы% production должны иметь возможность обращаться к файлу конфигурации или даже к файлам журнала. Есть еще решение добавить их в нужные группы (mysql...) и установить хорошее разрешение. Но я не хочу, чтобы пользователь модифицировал всех пользователей, я не хочу изменять стандартные разрешения, поскольку они могут меняться после каждого обновления.
С другой стороны, установка acls и / или смешивание setuid/ setgid для каталогов - это то, что я мог бы легко сделать, не "искажая" стандартный дистрибутив.
Что Вы думаете об этом?
Если взять пример mysql, это будет выглядеть так:
setfacl d:g:production:rx,d:other::---,g:production:rx,other::--- /var/log/mysql /etc/mysql
Как вы думаете, это хорошая практика, или я должен определенно usermod -G mysql и играть со стандартной системой разрешений?
Спасибо
3 ответа
Лучшие практики: ведите файл sudoers и используйте sudo.
На моем персональном компьютере я предпочитаю setuid/gid, но я единственный на своем компьютере; и я не делаю это с чем-то явно опасным, как rm,
Лучшие практики (и наиболее распространенные) имеют тенденцию к использованию sudo, Sudo предлагает вам детальное управление, а конфигурация может обрабатывать несколько машин одновременно.
Использование ACL может дополнить это - sudo обрабатывает операции как root; ACL предоставляют и отнимают права на каталоги и файлы для пользователей и групп. Я бы не рассчитывал на setgid и setuid, чтобы сделать что-нибудь разумное.
Я также реализовал бы группу колес; это поможет повысить безопасность. Проверьте, если ваш su Программа поддерживает колесную группу.
Еще одна вещь: если у вас есть view или же less как способ чтения файла журнала, то вы рискуете: обе эти программы предлагают доступ к оболочке.
Мне кажется, что опция sudoers немного более компактна, чем setuid/setguid/ACL.
Без группировки пользователей ваш ACLS будет очень длинным. И если вы делаете группу пользователей, вы возвращаетесь в то же место, где вы начали.
Большая проблема заключается в том, что без какого-либо централизованного управления им контроль доступа распространяется по всей файловой системе. Конечно, вы можете легко обойти это с помощью макросов, шаблонов, управления конфигурациями и так далее. Но это совсем другой слой, который ничего не делает, чтобы уменьшить сложность.
В моем небольшом магазине Drupal я довольно широко использую ACL для всех рабочих файлов, но sudo для всего доступа к управлению. Слой управления конфигурацией, который я использую, является Ansible, и приятно то, что я могу легко шаблонизировать пользователей, их роли и, следовательно, какие группы они получают, на каких машинах и так далее. Sudoers управляется аналогичным образом. Это кажется мне лучшей практикой, потому что это наиболее прозрачно.
Конечно, у меня, вероятно, не так много пользователей или групп, как у вас. Я мог бы представить включение ACL в управление конфигурациями. Но, судя по всему, я не вижу простого способа управлять многими машинами, многими пользователями и многими группами таким образом.