Эрика Виндиш предупреждает, что пользовательские пространства имен Linux могут быть недостаточно безопасными. Если у реального root-пользователя была удалена возможность SYS_CAP_ADMIN, но затем он создает пользовательское пространство имен, возможность восстанавливается для поддельного root-пользователя. До создания пространства имен 'mount' был бы отклонен, но после создания системный вызов 'mount' снова заработает, хотя и в ограниченном виде. Это достаточно значимо, чтобы при реальном root-пользователе и ядре с пользовательскими пространствами имен возможности Linux могли быть полностью подорваны.
Страница руководства user_namespaces подтверждает, что дочерний процесс, созданный с помощью clone(2) с CLONE_NEWUSER, начинает с полного набора возможностей в новом пользовательском пространстве имен. Пользовательские пространства имен допускают "интересные" пересечения моделей безопасности, предоставляя полные root-возможности новому пространству имен. Это может позволить CLONE_NEWUSER эффективно использовать CAP_NET_ADMIN над другими сетевыми пространствами имен, особенно если контейнеры не используются. Процессы с CAP_NET_ADMIN имеют большую поверхность атаки и привели к ряду уязвимостей ядра, что потенциально позволяет непривилегированному пользовательскому пространству имен атаковать подсистему сетевого взаимодействия ядра.
Демонстрации показывают, что на хосте с скомпилированными пользовательскими пространствами имен пользователь может создать мост с помощью ioctl с SIOCBRADDBR, хотя установка файловых возможностей с помощью cap_set_file не удается. Ubuntu включает CONFIG_USER_NS, но патчит его так, чтобы непривилегированное использование можно было отключить с помощью sysctl unprivileged_userns_clone. Конфигурация ядра по умолчанию имеет значение 'n' для пользовательских пространств имен, рекомендуя MEMCG для ограничения памяти непривилегированных пользователей.
Источник: Hacker News · Сводку подготовил HeadlinesBriefing