Posso alterar com segurança a propriedade do grupo /var/log/auth.log?

Question

Eu sou o administrador do Splunk trabalhando com um sistema Ubuntu 12.04 LTS e quero coletar eventos do /var/log/auth.log.

-rw-r----- 1 root adm 16534643 Jan  8 09:49 /var/log/auth.log

O Splunk é executado como um usuário normal, splunk .

$ id splunk
uid=1984(splunk) gid=1984(splunk) groups=1984(splunk)

Normalmente, eu usaria esse comando para tornar o grupo de arquivos legível pelo grupo splunk.

$ chgrp splunk /var/log/auth.log
-rw-r----- 1 root splunk 16534643 Jan  8 09:49 /var/log/auth.log

Isso funciona bem em outras distribuições do Linux e eu suponho que isso também é bom para o Ubuntu. Mas eu quero perguntar, batendo o adm porque eu (na verdade, o outro grupo que possui a caixa) dores de cabeça no futuro? Eu não sou um usuário privilegiado no sistema, por isso não posso verificar coisas como / var / log / cron / adm ou mail para a conta adm. Eu também estou assumindo que o logrotate honrará o novo proprietário do meu grupo por novos arquivos.

(Antes de perguntar, o acesso ao índice de splunk para auth.log é restrito a um número limitado de pessoas.)

    

Answer 1

Acompanhamento: Como ninguém nunca deu uma razão pela qual a propriedade do grupo "adm" era importante, alterei a propriedade do grupo para "splunk".

Após 6 meses, nenhum problema foi notado. Decidi não conceder privilégios de grupo adicionais ao usuário do splunk adicionando-o ao grupo "adm". Eu raciocinei que poderia dar à conta adm o privilégio extra de ser membro do grupo "splunk", se necessário.

    

Answer 2

O grupo adm pode ser importante se uma ferramenta de segurança como o AppArmor (consulte link ) estiver sendo usada para segurança adicional.

Eu mencionei isso apenas porque tive problemas estranhos (falhas de acesso) ao tentar configurar o bind no Ubuntu e usando diretórios diferentes. Ou seja, o bind se recusou a trabalhar com alterações que faziam sentido para mim, mas não eram os padrões do AppArmor. Como eu não queria reconfigurar o AppArmor, voltei aos seus padrões - e sudo su quando preciso fazer alterações. Para um sistema de usuário único, tudo bem, mas eu não gostaria desse jeito em um sistema de produção.

Por último, o grupo adm pode ser importante se você for auditado - ou seja, um auditor pode considerá-lo uma violação da integridade do sistema se não for um grupo adm. Uma forma pela qual você pode "passar" é usando ACLs (Access Control Lists) - veja link para mais informações sobre isso.