Posso restringir o dmesg a um grupo?

Question

Eu entendo que, por razões de segurança (como a randomização de endereços), faz algum sentido não permitir que todo usuário leia o dmesg do kernel. O Linux permite restringir o dmesg ao usuário root usando: sysctl -w kernel.dmesg_restrict = 1 .

Esse sysctl força todos que querem usar o dmesg a preceder sudo , o que é um problema para mim.

Eu gostaria de algo entre os dois. Eu quero algumas contas de usuário em minhas máquinas para ter acesso sem sangue ao dmesg, mas não daemons como o apache ou não-usuários como www-data.

Idealmente, o acesso dmesg seria restrito a um determinado grupo (digamos, adm ).

Qual é a maneira mais limpa de fazer isso?

Notas de rodapé:

¹ Embora eu goste de sudo em conceito, acredito que deveria ser uma palavra de quatro letras: usada judiciosamente pelos sábios como um epíteto perfeito para as raras ocasiões em que nada mais seria suficiente. Infelizmente, vejo pessoas usando o sudo para muitas tarefas mundanas hoje em dia sem pensar duas vezes. Colocar as pessoas no hábito de usar excessivamente o sudo é um problema de segurança pior do que potenciais vazamentos de endereço do kernel.

² Eu mencionei "cleanest", porque suspeito que algumas soluções, como chmod 4750 /bin/dmesg , possam ter implicações potencialmente pilosas na segurança.

Atualização : Aceitei a solução setcap do Ikkachu, mas espero que em futuras versões do Linux haja uma resposta mais clara e mais geral. Talvez uma terceira configuração de sysctl para o dmesg_restrict que esteja entre 0 (todos) e 1 (somente raiz), permita que os administradores de sistema especifiquem grupos confiáveis.

    

Answer 1

Se, por "sem sentido", você quiser escrever apenas dmesg ou semelhante na linha de comando, a solução mais simples seria criar um script que chame /bin/dmesg a sudo , e configure o sudo para que isso aconteça sem pedir uma senha.

Então, algo assim:

echo 'username ALL = NOPASSWD:/bin/dmesg  ' >> /etc/sudoers
cat <<'EOF' > ./dmesg
#!/bin/sh
sudo /bin/dmesg "$@"
EOF
chmod +x ./dmesg

e, em seguida, coloque ./dmesg em algum lugar do seu caminho.

Isso funciona desde que você não tenha outro programa que precise ler o buffer de mensagem do kernel diretamente, sem passar pelo /bin/dmesg . Mas então, definir /bin/dmesg setuid teria a mesma limitação. Executá-lo via sudo é provavelmente mais seguro do que simplesmente executá-lo setuid.

Como um aparte, alterar as permissões em /dev/kmsg não funciona, mesmo que dmesg tente lê-lo. Ele volta para a chamada de sistema syslog(2) .

Se isso não for suficiente, você poderá fazer isso com os recursos . O dmesg_restrict sysctl restringe a leitura do log para processos com CAP_SYSLOG , portanto, precisamos apenas que isso seja definido.

Então, algo assim:

# cp /bin/dmesg /bin/dmesg.capable 
# chown .adm /bin/dmesg.capable
# chmod 710 /bin/dmesg.capable
# setcap cap_syslog=ep /bin/dmesg.capable

Os usuários do grupo adm agora devem poder usar /bin/dmesg.capable para exibir o log.

Embora os recursos sejam notórios, muitos deles fornecem maneiras de contornar o restante dos sistemas de controle de acesso, embora a concessão de apenas CAP_SYSLOG seja provavelmente melhor do que executar dmesg como raiz completa.

Outras opções que vêm à mente são o SELinux, seccomp e apenas o antigo patch do kernel para permitir a leitura do log por um determinado grupo.