Вопрос или проблема
из https://www.stigviewer.com/stig/red_hat_enterprise_linux_8/2021-12-03/finding/V-230548
RHEL 8 должен отключить использование пространств имен пользователей.
Неэффективно для операционных систем обеспечивать или устанавливать по умолчанию функционал, превышающий требования или цели миссии. Эти ненужные возможности или услуги часто упускаются из виду и, следовательно, могут оставаться незашищенными. Они увеличивают риск для платформы, предоставляя дополнительные векторы атак. Команда sysctl –system загрузит настройки из всех системных конфигурационных файлов. Все конфигурационные файлы сортируются по своим именам в лексикографическом порядке, независимо от того, в каких директориях они находятся. Если несколько файлов указывают одну и ту же опцию, приоритет будет у записи в файле с наименованием, лексикографически последним. Файлы читаются из директорий по следующему списку сверху вниз. Как только загружается файл с данным именем файла, любой файл с тем же именем в последующих директориях игнорируется. /etc/sysctl.d/.conf /run/sysctl.d/.conf /usr/local/lib/sysctl.d/.conf /usr/lib/sysctl.d/.conf /lib/sysctl.d/*.conf /etc/sysctl.conf Исходя из вышесказанного, если в директории “/etc/sysctl.d/” будет создан конфигурационный файл, начинающийся с “99-“, он будет иметь приоритет над любым другим конфигурационным файлом в системе.
Примечание: Пространства имен пользователей используются в основном для контейнеров Linux. Если контейнеры используются, это требование не применяется.
Начиная с Linux 5.10, всем пользователям разрешено по умолчанию создавать пространства имен пользователей. Это позволит программам, таким как веб-браузеры и менеджеры контейнеров, создавать более ограниченные песочницы для недоверенного или менее доверенного кода без необходимости запускаться от имени root или использовать помощник с setuid-root.
Предыдущий по умолчанию в Debian ограничивал эту функцию процессами, работающими от имени root, поскольку это потенциально создавало больше проблем с безопасностью в ядре. Однако, поскольку реализация этой функции улучшилась, мы уверены, что риск ее включения перевешивается преимуществами безопасности, которые она предоставляет.
и https://man7.org/linux/man-pages/man7/user_namespaces.7.html
В RHEL-8.10 мой /opt/anaconda3/bin/spyder завершает работу с ошибкой при запуске:
FATAL:credentials.cc(137)] Проверка не удалась: error == EPERM || error == EUSERS || error == EINVAL || error == ENOSYS. :
Нет места на устройстве
В ходе собственных испытаний я обнаружил, что установка user.max_user_namespaces = 5 или более в /etc/sysctl.conf решила проблему с завершением работы spyder, а установка этого значения в 0 была единственной причиной проблемы.
-
Что касается функциональности того, что я до сих пор прочитал о user.max_user_namespaces, действительно ли имеет смысл задать ему какое-то значение (кроме 0) для повышения безопасности?
-
Является ли утверждение stigviewer о том, что это прежде всего для контейнеров Linux, точным?
-
Может ли кто-то перечислить другое программное обеспечение, использующее пространства имен пользователей, где установка этого значения в ноль вызовет аналогичную проблему?
-
Является ли написание программного обеспечения в Linux с использованием пространств имен пользователей плохим или хорошим в контексте безопасности?
Что касается функциональности того, что я до сих пор прочитал о user.max_user_namespaces, действительно ли имеет смысл задать ему какое-то значение (кроме 0) для повышения безопасности?
На это невозможно ответить, не зная конкретных моделей угроз, которые вы рассматриваете.
Является ли утверждение stigviewer о том, что это прежде всего для контейнеров Linux, точным?
В общем масштабе, вероятно, больше систем Linux запускает контейнеры, чем других программ, способных использовать пространства имен пользователей, поэтому, строго говоря, да. Однако учитывая, что современные веб-браузеры используют пространства имен пользователей, я подозреваю, что это утверждение неточно для пользователей Linux на десктопах.
Может ли кто-то перечислить другое программное обеспечение, использующее пространства имен пользователей, где установка этого значения в ноль вызовет аналогичную проблему?
Веб-браузеры (и программы с компонентами веб-браузеров), например. Песочница веб-браузера не будет работать как ожидалось; в большинстве случаев это не остановит браузер полностью. В вашем конкретном случае сбой вызван компонентом веб-браузера. (По этой ссылке есть предложенное обходное решение, --no-web-widgets.)
Является ли написание программного обеспечения в Linux с использованием пространств имен пользователей плохим или хорошим в контексте безопасности?
Несмотря на мой «бесплатный выход из объяснений», упомянутый выше, пространства имен пользователей – это дополнительный инструмент в арсенале разработки программного обеспечения, и наличие большего количества инструментов, которые можно использовать, можно считать хорошим с точки зрения безопасности, если они используются разумно. Возможность создавать песочницы с разумными ограничениями в разрешениях, на мой взгляд, лучше в большинстве случаев.
Ответ или решение
Ответ на вопрос о рационализации параметра user.max_user_namespaces, установив его в 0
Установка параметра user.max_user_namespaces в значение 0 в операционной системе RHEL 8 имеет свои обоснования, а также потенциал вызвать определенные проблемы.
Безопасность и функциональность
-
Безопасность:
В рамках STIG (Security Technical Implementation Guide) для RHEL 8 рекомендуется отключить использование пространств имен пользователей (user namespaces), поскольку они могут увеличить поверхность атаки на систему. Эта рекомендация основана на предположении, что дополнительные функции, не требуемые для выполнения задач, могут представлять собой потенциальные уязвимости. Заключение в том, что более строгая конфигурация системы повышает ее безопасность, однако это требует анализа конкретной угрозы вашего окружения. -
Функциональность:
Несмотря на рекомендации по безопасности, следует учитывать, что пользовательские пространства имен используются не только для контейнеров. Например, современные веб-браузеры (такие как Firefox, Chrome) и некоторые приложения, использующие компоненты веб-браузеров, также применяют эту функциональность, чтобы создать более безопасные песочницы для не доверенного кода. Отключение этой функции может привести к сбоям в работе таких приложений, как в ситуации с запуском Spyder, который вы упомянули.
Практические аспекты и другие приложения
-
Программное обеспечение:
В дополнение к веб-браузерам, другие приложения, использующие пользовательские пространства имен, могут включать инструменты для разработки, такие как Docker, а также различные интегрированные среды разработки (IDE) и редакторы кода. Установкаuser.max_user_namespacesв 0 ограничивает их функциональность, что может привести к сбоям или неожиданному поведению. -
Работа с безопасностью:
Использование пользовательских пространств имен в разработке программного обеспечения требует ответственного подхода. Они могут служить мощным инструментом для повышения безопасности, если будут использованы правильно. Создание ограниченных окружений с минимальными правами во многих случаях предпочтительнее, чем предоставление полного доступа. Это позволяет снижать риски, связанные с выполнением потенциально небезопасного кода.
Заключение
Установка user.max_user_namespaces в 0 действительно может повысить безопасность системы, но в то же время приведет к проблемам с функциональностью приложений, которые зависят от этой возможности. Для разработчиков и пользователей, ориентирующихся на безопасность, целесообразно использовать настройки, которые учитывают баланс между безопасностью и функциональностью. Важно тщательно проанализировать архитектуру вашего приложения и его зависимости, чтобы понять, как лучше всего управлять параметрами пространство имен пользователей в вашей среде.
Таким образом, ответ на ваш вопрос о том, является ли установка user.max_user_namespaces в 0 разумным выбором, зависит от конкретного контекста и инженерных требований системы.