Como Ler Logs do Linux Sem Root (Guia de Permissões)

Na maioria das distribuições, duas pertenças de grupo cobrem quase tudo o que um analista precisa: adm para os logs de texto em /var/log no Debian e Ubuntu, e systemd-journal para o diário completo do sistema. Adicione a conta com sudo usermod -aG adm,systemd-journal <user> e inicie uma nova sessão de login. Alguns logs permanecem restritos ao root por design, notavelmente /var/log/secure e /var/log/messages em sistemas da família Red Hat e tudo sob /var/log/audit. Para esses, use sudo com escopo restrito, não um shell root.

Dar acesso root a alguém apenas para que possa ler logs é o tipo de atalho que aparece na próxima auditoria ou no próximo incidente. Este guia cobre a maneira de menor privilégio, além das armadilhas que fazem com que “basta adicioná-los a um grupo” seja menos simples do que parece.

Comece Gratuitamente

Quem pode ler o quê

A propriedade exata varia com a distribuição e versão, então verifique na própria máquina:

id
ls -l /var/log/auth.log /var/log/secure 2>/dev/null
getfacl /var/log/journal 2>/dev/null

Opção 1: Pertença a grupos

sudo usermod -aG adm,systemd-journal analyst

Dois detalhes são importantes. O -a não é opcional: sem ele, usermod -G substitui os grupos do usuário em vez de adicioná-los. E as mudanças de grupo só se aplicam a novas sessões. Saia e entre novamente ou inicie um novo shell de login antes de testar. “Eu adicionei o grupo e ainda diz que a permissão foi negada” geralmente é uma sessão antiga.

Em sistemas da família Red Hat, adm não desbloqueia /var/log/secure ou /var/log/messages. Esses arquivos são somente root lá. Use a Opção 2 ou 3.

Opção 2: Sudo restrito para logs somente root

Conceda comandos específicos, não um shell. Crie /etc/sudoers.d/log-readers com visudo -f:

%logreaders ALL=(root) NOPASSWD: /usr/sbin/ausearch, /usr/local/bin/read-secure-log

read-secure-log é um pequeno script de propriedade root (modo 0755, de propriedade de root) que faz exatamente uma coisa:

#!/bin/sh
exec /usr/bin/zcat -f /var/log/secure /var/log/secure-*

Por que um invólucro em vez de cat /var/log/secure* em sudoers? Porque um * em um argumento sudoers corresponde a qualquer coisa, incluindo espaços. cat /var/log/secure /etc/shadow corresponde a cat /var/log/secure*. Um invólucro sem argumentos não tem tal falha.

Não conceda journalctl via sudo. Ele abre um pager (less), e !sh dentro do less dá acesso a um shell root. Para acesso ao diário, use o grupo systemd-journal em vez disso.

Opção 3: Propriedade de grupo que sobrevive à rotação

Definir um ACL diretamente funciona até a próxima rotação: sudo setfacl -m g:logreaders:r /var/log/secure. Então o arquivo é recriado, e o ACL não existe mais. Para que o acesso seja mantido, faça com que novos arquivos sejam criados com o grupo certo desde o início, em ambos os lugares que os criam:

• logrotate, na entrada do arquivo: create 0640 root logreaders
• rsyslog, na ação que o escreve: action(type=”omfile” file=”/var/log/secure” fileGroup=”logreaders” fileCreateMode=”0640″)

Teste-o com logrotate -f em uma máquina não produtiva antes de implantá-lo.

Contêineres

Não adicione analistas ao grupo docker apenas para ler logs de contêiner. A pertença ao docker é efetivamente root nesse host. Obtenha logs de contêiner do seu coletor de logs ou SIEM, ou peça à equipe de plataforma acesso somente leitura lá.

Quando dá errado