Systemd PrivateTmp= истинные последствия для безопасности

Я отслеживаю доступное дисковое пространство на серверах Ubuntu, используя Nagios Core, NRPE и check_disk.

В предыдущих версиях Ubuntu я получал вывод, похожий на этот:

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

В Ubuntu 18.04.1 вместо этого я получаю:

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

Мне показывают неверную точку монтирования /var/tmp для корня / раздел. Я проследил, чтобы это поведение зависело от наличия PrivateTmp=true в nagios-nrpe-server.service:

  • Я пошел смотреть /var/tmp и нашел каталог с именем systemd-private-c5b5d3d362364af19af640147f2cb844-nagios-nrpe-server.service-4uILRy
  • затем проверил определение сервиса и заметил PrivateTmp=true (чего нет, например, для NRPE2 в Ubuntu 16.04)
  • наконец, попытался удалить строку и корневая точка монтирования была обнаружена как /

Я чувствую, что сталкиваюсь с тремя вариантами:

  1. Живи с этим.

  2. Удалить PrivateTmp=true,

  3. Найти разумное решение.

Я склонен просто жить с этим, но если бы я больше знал о последствиях отсутствия частного /tmp для услуги я мог бы сделать осознанный выбор по поводу варианта 2.

Оптимальным решением может быть поиск обходного пути, инструктаж check_disk вернуть правильную информацию о точке монтирования даже в этом случае. Не имея доступа к системе /tmp не должен представлять собой препятствие.

Вопрос: Пожалуйста, проиллюстрируйте последствия PrivateTmp=true, объясняя, почему это будет рекомендовано и в каких случаях и с какими оговорками его можно удалить.

Вторичный вопрос: есть ли разумный обходной путь, чтобы сделать check_disk или эквивалентный инструмент отображает правильную корневую точку монтирования даже при запуске службой с PrivateTmp=true?

Дополнительная информация:

Полная команда: /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /dev/mapper/vg-root, Когда запускается локально, даже с nagios пользователь, вывод правильно показывает /, При удаленном запуске с сервера Nagios с помощью: /usr/local/libexec/nagios/check_nrpe2 -H 192.168.1.2 -c check_root, вывод показывает /var/tmp вместо ожидаемого /,

Источник

1 ответ

Решение

Я могу воспроизвести это поведение, предоставив блочное устройство check_disk вместо точки монтирования.

Например:

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

Но используя точку монтирования, я получаю ожидаемое поведение:

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

Такое поведение как-то связано с настройкой PrivateTmp= в системном блоке. Когда я удаляю это из nagios-nrpe-server.service, затем check_disk возвращает ожидаемый результат, когда также предоставляется блочное устройство. Я немного поигрался с тривиальным сервисом, который просто побежал /bin/df с PrivateTmp=true но я не смог найти никакой очевидной проблемы там. Он также дал правильные результаты.

Я бы сказал, что лучше всего, если вам действительно нужно проверять диски по блочному устройству, а не по точке монтирования, - это сообщить о проблеме разработчикам Nagios NRPE, чтобы они могли действительно покопаться в коде и найти что угодно. является.

Источник
Другие вопросы по тегам