Systemd PrivateTmp = implicações de segurança verdadeiras

1

Eu monitorei o espaço em disco disponível nos servidores Ubuntu usando o Nagios Core , NRPE e check_disk .

Com versões anteriores do Ubuntu, eu costumava ter uma saída semelhante a esta:

DISK OK - free space: / 43754 MB (80% inode=86%):

No Ubuntu 18.04.1, em vez disso, recebo:

DISK OK - free space: /var/tmp 43754 MB (80% inode=86%):

Foi mostrado um ponto de montagem incorreto /var/tmp para a partição raiz / . Eu acompanhei esse comportamento para depender de ter PrivateTmp=true em nagios-nrpe-server.service :

  • Eu fui pesquisar /var/tmp e encontrei um diretório chamado systemd-private-c5b5d3d362364af19af640147f2cb844-nagios-nrpe-server.service-4uILRy
  • examinou a definição do serviço e notou PrivateTmp=true (que não está lá, por exemplo, para NRPE2 no Ubuntu 16.04)
  • finalmente, tentei excluir a linha e o ponto de montagem raiz foi detectado como /

Eu sinto que estou enfrentando três opções:

  1. Viva com ele.

  2. Remover PrivateTmp=true .

  3. Encontre uma solução razoável.

Estou inclinado a apenas viver com isso, mas se eu estivesse mais ciente das implicações de não ter um /tmp privado para o serviço, eu poderia fazer uma escolha informada sobre a opção 2.

A solução ideal poderia ser encontrar uma solução alternativa, instruindo check_disk a retornar as informações corretas sobre o ponto de montagem, mesmo neste caso. Não conseguir acessar o sistema /tmp não deve representar um obstáculo.

Pergunta: Por favor, ilustre as implicações de PrivateTmp=true , explicando por que ele seria recomendado e em quais casos e com quais ressalvas ele pode ser removido.

Pergunta secundária: Existe uma solução sensata para fazer com que check_disk ou uma ferramenta equivalente exiba o ponto de montagem raiz correto mesmo quando executado por um serviço com PrivateTmp=true ?

Informações adicionais:

O comando completo é: /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /dev/mapper/vg-root . Quando executado localmente, mesmo com o usuário nagios , a saída mostra corretamente / . Quando executado remotamente a partir do servidor Nagios com: /usr/local/libexec/nagios/check_nrpe2 -H 192.168.1.2 -c check_root , a saída mostra /var/tmp em vez do esperado / .

    
por simlev 15.11.2018 / 11:28

1 resposta

1

Eu posso reproduzir esse comportamento fornecendo o dispositivo de bloco para check_disk em vez do ponto de montagem.

Por exemplo:

root@cosmic:~# grep check_root /etc/nagios/nrpe.cfg 
command[check_root]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /dev/sda1
root@cosmic:~# /usr/lib/nagios/plugins/check_nrpe -H 127.0.0.1 -c check_root
DISK OK - free space: /var/tmp 6451 MB (68% inode=78%);| /var/tmp=3033MB;8010;9011;0;10013
root@cosmic:~# /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /dev/sda1
DISK OK - free space: / 6451 MB (68% inode=78%);| /=3033MB;8010;9011;0;10013

Mas usando o ponto de montagem, obtenho o comportamento esperado:

root@cosmic:~# grep check_root /etc/nagios/nrpe.cfg 
command[check_root]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /
root@cosmic:~# /usr/lib/nagios/plugins/check_nrpe -H 127.0.0.1 -c check_root
DISK OK - free space: / 6451 MB (68% inode=78%);| /=3033MB;8010;9011;0;10013
root@cosmic:~# /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /
DISK OK - free space: / 6451 MB (68% inode=78%);| /=3033MB;8010;9011;0;10013

Este comportamento parece estar relacionado de alguma forma à configuração de PrivateTmp= na unidade systemd. Quando eu remover isso de nagios-nrpe-server.service , então check_disk retornará o resultado esperado quando receber o dispositivo de bloco também. Eu brinquei um pouco com um serviço trivial que apenas rodava /bin/df com PrivateTmp=true , mas não encontrei nenhum problema óbvio lá. Também retornou os resultados corretos.

Eu sugeriria que a melhor coisa a fazer, se você realmente precisa ser capaz de verificar discos por dispositivo de bloco em vez de ponto de montagem, é relatar um problema para os desenvolvedores do Nagios NRPE para que eles possam realmente investigar o código e encontre o que quer que seja.

    
por 15.11.2018 / 15:34