по какой-то причине, которую я не очень понимаю, всем нужен sudo для всех и вся. На работе у нас даже есть столько записей, сколько есть способ прочитать файл журнала (голова / хвост / кошка / еще, ...).
Я думаю, здесь sudo побеждает.
Я бы предпочел использовать сочетание каталогов setgid / setuid и добавлять ACL кое-где, но мне действительно нужно знать, каковы лучшие практики, прежде чем начинать.
На наших серверах есть% admin,% production,% dba,% users, то есть много групп и много пользователей. Каждая служба (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 и играть со стандартной системой разрешений?
Спасибо
Лучшие практики (и наиболее распространенные) обычно используют sudo. Sudo предлагает вам детальный контроль, а конфигурация может обрабатывать сразу несколько машин.
Использование ACL может дополнить это - sudo обрабатывает операции как root; ACL дают и отнимают права на каталоги и файлы для пользователей и групп. Я бы не стал рассчитывать на то, что setgid и setuid сделают что-нибудь разумное.
Я бы также реализовал колесную группу; это поможет повысить безопасность. Проверьте, есть ли у вас su Программа поддерживает колесную группу.
Еще одно: если у вас есть view или less в качестве способа чтения файла журнала вы подвергаетесь риску: обе эти программы предлагают доступ к оболочке.
Лучшие практики: ведите файл sudoers и используйте sudo.
На моей персональной машине я предпочитаю setuid / gid, но я единственный на своем компьютере; и я не делаю этого ни с чем явно опасным, как rm.
Мне кажется, что опция sudoers немного компактнее, чем setuid / setguid / ACL.
Без группировки пользователей ваши ACLS будут очень длинными. А если вы группируете пользователей, вы возвращаетесь к тому же месту, где начали.
Более серьезная проблема заключается в том, что без какого-либо централизованного управления контроль доступа распространяется по всей файловой системе. Конечно, вы можете легко обойти это с помощью макросов, шаблонов, управления конфигурацией и так далее. Но это совершенно другой уровень, который ничего не делает для уменьшения сложности.
В моем небольшом магазине Drupal я довольно широко использую ACL для всех рабочих файлов, кроме sudo для доступа к управлению. Уровень управления конфигурацией, который я использую, - это Ansible, и в нем хорошо то, что я могу легко создавать шаблоны пользователей, их ролей и, следовательно, того, какие группы они входят, на каких машинах и т. Д. Судоерс управляется аналогичным образом. Мне это кажется хорошей практикой, потому что она наиболее прозрачна.
Конечно, у меня, вероятно, не так много пользователей или групп, как у вас. Я мог бы представить себе включение ACL в управление конфигурацией. Но, хоть убей, я не вижу простого способа управлять таким образом множеством машин, множеством пользователей и множеством групп.