Implicações de segurança do Linux para sudo, su para conta de serviço e adicionar grupo secundário ao administrador do Tomcat?

Question

Eu tenho uma conta nomeada para acessar um host Linux. O Tomcat está sendo executado em uma conta de serviço chamada "tomcat"

Eu periodicamente preciso fazer funções administrativas como modificar o tomcat-users.xml que está configurado como

-rw-------. 1 tomcat tomcat   1671 Mar 25 20:50 tomcat-users.xml

Eu quero auditar as alterações. Eu deveria

• Forneça aos usuários nomeados sudo com direitos para editar o arquivo
• Conceder aos usuários nomeados o direito de su para a conta do tomcat e fazer as alterações necessárias (seja via sudo ou dando aos administradores a senha do tomcat)
• Adicione permissões para permitir que os membros do grupo tomcat editem o arquivo e adicionem o tomcat como um grupo secundário aos usuários nomeados.

usar o sudo abriria possíveis erros de configuração que dariam aos usuários nomeados mais acesso do que eu pretendia e permitiriam que eles usassem o sudo -i e ignorassem a auditoria. Alterar as permissões de arquivo expande quem pode ler o arquivo parece arriscado.

Estou realmente procurando por riscos & vantagens / desvantagens que eu não cobri acima para ajudar a decidir a abordagem a tomar e não apenas opiniões e "eu faço desta forma".

    

Answer 1

A única maneira de ter uma trilha de auditoria confiável é trabalhar com uma política de privilégio mínimo, ou seja, negar o acesso por padrão.

Se você for com sudo access, certamente poderá limitar o que os usuários podem e não podem fazer; mas você também precisa estar ciente das advertências que podem se aplicar.

Nesse caso, seu requisito é conceder acesso a um grupo de usuários para editar um arquivo específico.

As melhores práticas determinam que cada usuário tenha uma conta pessoal. Não é necessário fazer com que esses usuários pertençam a nenhum grupo, pois isso já é coberto por sudo .

Supondo que seus usuários pertençam ao grupo operators , um sudorule seria semelhante a:

Cmnd_Alias TOMCAT_COMMANDS = sudoedit /path/to/tomcat-users.xml
Host_Alias TOMCAT_HOSTS = foo.example.com, bar.example.com

Defaults log_host
Defaults log_output
Defaults syslog_badpri=alert
Defaults syslog_goodpri=notice
Defaults:%operators editor=/usr/bin/rvim

%operators TOMCAT_HOSTS = (tomcat)PASSWD: TOMCAT_COMMANDS

Isso garante que eles não escapem do editor, pois são forçados a usar rvim e fornecem alguns padrões sensatos para registrar suas atividades. Você pode reforçar ainda mais a política sudo e pode adicionar mais funcionalidades a ela. Este é um exemplo.

Outra maneira de realizar algo semelhante é alterar o controle de versão para esse arquivo e gerenciá-lo usando um sistema de gerenciamento de configuração.

O RBAC para esse tipo de sistema é um tópico amplo, como é a auditoria. Cabe a você coletar e analisar os logs gerados.