por uma razão que eu realmente não entendo, todo mundo quer sudo para tudo e todos. No trabalho, temos tantas entradas quantas forem as maneiras de ler um arquivo de log (head/tail/cat/more, ...).
Eu acho que o sudo está derrotando aqui.
Prefiro usar uma mistura de diretórios setgid/setuid e adicionar ACL aqui e ali, mas realmente preciso saber quais são as práticas recomendadas antes de iniciar.
Nossos servidores possuem %admin, %production, %dba, %users - ou seja, muitos grupos e muitos usuários. Cada serviço (mysql, apache, ...) tem sua própria maneira de instalar privilégios, mas os membros do grupo %production devem poder consultar o arquivo de configuração ou até mesmo os arquivos de log. Ainda existe a solução para adicioná-los nos grupos corretos (mysql...) e definir a boa permissão. Mas não quero modificar todos os usuários, não quero modificar as permissões dos padrões, pois elas podem mudar após cada atualização.
Por outro lado, definir acls e/ou misturar setuid/setgid em diretórios é algo que eu poderia fazer facilmente sem "desfigurar" a distribuição padrão.
O que você pensa sobre isso ?
Tomando o exemplo do mysql, ficaria 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 usermod -G mysql e brincar com o sistema de permissões padrão?
Obrigado
Responder1
Melhores práticas: mantenha o arquivo sudoers e use sudo.
Na minha máquina pessoal, prefiro setuid/gid, mas sou o único no meu computador; e eu não faço isso com nada flagrantemente perigoso como rm.
Responder2
As melhores práticas (e as mais comuns) tendem a usar sudo. Sudo oferece controle refinado e a configuração pode lidar com várias máquinas ao mesmo tempo.
O uso de ACLs pode complementar isso - sudolida com operações como root; As ACLs concedem e retiram direitos a diretórios e arquivos para usuários e grupos. Eu não contaria com setgid e setuid para fazer algo razoável.
Eu também implementaria o grupo wheel; isso ajudará a aumentar a segurança. Verifique se o seu suprograma suporta o grupo wheel.
Mais uma coisa: se você tem viewou lesstem como ler um arquivo de log, então você está em risco: ambos os programas oferecem acesso shell.
Responder3
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ê agrupar usuários, você voltará ao mesmo lugar onde começou.
O maior problema é que sem algum tipo de gerenciamento centralizado, o controle de acesso se espalha por todo o sistema de arquivos. É claro que você pode facilmente contornar isso com macros, modelos, gerenciamento de configuração e assim por diante. Mas essa é uma outra camada que não faz nada para reduzir a complexidade.
Na minha pequena loja Drupal eu uso ACLs extensivamente para todos os arquivos de trabalho, mas sudo para todos os acessos de gerenciamento. A camada de gerenciamento de configuração que estou usando é Ansible e o bom disso é que posso facilmente criar modelos de usuários, suas funções e, portanto, quais grupos eles recebem, em quais máquinas e assim por diante. Sudoers é gerenciado de forma semelhante. Isso me parece uma prática recomendada porque é mais transparente.
É claro que provavelmente não tenho tantos usuários ou grupos quanto você. Eu poderia imaginar colocar ACLs no gerenciamento de configuração também. Mas, sinceramente, não vejo uma maneira direta de gerenciar muitas máquinas, muitos usuários e muitos grupos dessa maneira.