Práticas recomendadas: mantenha o arquivo sudoers e use o sudo.
Na minha máquina pessoal, prefiro setuid / gid, mas sou o único no meu computador; e eu não faço isso para qualquer coisa descaradamente perigoso como rm .
por uma razão que eu realmente não entendo, todo mundo quer sudo para tudo e todos. No trabalho, temos até tantas entradas quanto a maneira de ler um arquivo de registro (cabeça / cauda / gato / mais, ...).
Eu acho que o sudo está derrotando aqui.
Eu prefiro usar uma mistura de diretórios setgid / setuid e adicionar ACL aqui e ali, mas eu realmente preciso saber quais são as melhores práticas antes de iniciar.
Nossos servidores possuem% admin,% produção,% dba,% usuários, ou seja, muitos grupos e muitos usuários. Cada serviço (mysql, apache, ...) tem seu próprio caminho para instalar privilégios, mas os membros do grupo de produção% devem poder consultar o arquivo de configuração ou até os arquivos de log. Ainda há a solução para adicioná-los aos grupos certos (mysql ...) e definir a boa permissão. Mas eu não quero usermod todos os usuários, eu não quero modificar permissões de padrões, uma vez que poderia mudar após cada atualização.
Por outro lado, configurar acls e / ou mixar setuid / setgid em diretórios é algo que eu poderia facilmente fazer sem "desfigurar" a distribuição padrão.
O que você acha disso?
Tomando o exemplo mysql, seria assim:
setfacl d:g:production:rx,d:other::---,g:production:rx,other::--- /var/log/mysql /etc/mysql
Você acha que isso é uma boa prática ou devo definitivamente usar o user -G mysql e jogar com o sistema de permissões padrão?
Obrigado
Práticas recomendadas: mantenha o arquivo sudoers e use o sudo.
Na minha máquina pessoal, prefiro setuid / gid, mas sou o único no meu computador; e eu não faço isso para qualquer coisa descaradamente perigoso como rm .
As práticas recomendadas (e mais comuns) tendem a usar sudo . O Sudo oferece um controle refinado, e a configuração pode lidar com várias máquinas de uma só vez.
O uso de ACLs pode complementar isso - sudo manipula as operações como raiz; As ACLs dão e tiram direitos a diretórios e arquivos para usuários e grupos. Eu não contaria com setgid e setuid para fazer qualquer coisa razoável.
Eu também implementaria o grupo wheel; isso ajudará a aumentar a segurança. Verifique se o seu programa su suporta o grupo wheel.
Mais uma coisa: se você tiver view ou less como uma maneira de ler um arquivo de registro, estará correndo risco: ambos os programas oferecem acesso ao shell.
Parece-me que a opção sudoers é um pouco mais compacta que o setuid / setguid / ACL.
Sem agrupar usuários, seu ACLS será muito longo. E se você fizer usuários do grupo, estará de volta ao mesmo lugar em que começou.
O maior problema é que, sem algum tipo de gerenciamento central, o controle de acesso se espalha por todo o sistema de arquivos. É claro que você pode contornar isso com macros, modelos, gerenciamento de configuração e assim por diante. Mas essa é outra camada que não reduz a complexidade.Na minha pequena loja Drupal eu uso ACLs extensivamente para todos os arquivos de trabalho, mas sudo para todo o acesso de gerenciamento. A camada de gerenciamento de configuração que estou usando é Ansible e o bom disso é que posso facilmente modelar usuários, suas funções e, portanto, quais grupos eles obtêm, em quais máquinas e assim por diante. Sudoers é gerenciado de forma semelhante. Isso parece uma prática muito boa para mim porque é mais transparente.
Claro, provavelmente não tenho tantos usuários ou grupos quanto você. Eu poderia imaginar colocar ACLs no gerenciamento de configuração também. Mas para a vida de mim, não vejo uma maneira direta de gerenciar muitas máquinas, muitos usuários e muitos grupos dessa maneira.