Userns restrict: различия между версиями

Материал из ALT Linux Wiki
(kernel.unprivileged_userns_clone)
мНет описания правки
Строка 4: Строка 4:


В ALT, как и в некоторых других дистрибутивах, в частности в Debian и Ubuntu к ядру приложены различные патчи для управления доступностью создания новых USERNS для непривелигированных пользователей. В RHEL, судя по всему, user namespaces по умолчанию выключены ещё более глобально через <tt>user.max_user_namespaces = 0</tt>. В ALT используется реализация от Kees Cook, для переключения используется <tt>sysctl kernel.userns_restrict</tt>, однако значение по умолчанию выставлено в 1 (создание USERNS непривелигированными пользователями запрещено).
В ALT, как и в некоторых других дистрибутивах, в частности в Debian и Ubuntu к ядру приложены различные патчи для управления доступностью создания новых USERNS для непривелигированных пользователей. В RHEL, судя по всему, user namespaces по умолчанию выключены ещё более глобально через <tt>user.max_user_namespaces = 0</tt>. В ALT используется реализация от Kees Cook, для переключения используется <tt>sysctl kernel.userns_restrict</tt>, однако значение по умолчанию выставлено в 1 (создание USERNS непривелигированными пользователями запрещено).
Начиная с ядра 5.10.82 поддерживается также sysctl из Debian: <tt>kernel.unprivileged_userns_clone</tt>. Обратите внимание на то, что у него обратное поведение: для значение 1 разрешает непривелигированные USERNS, а значение 0 — запрещает.
Начиная с ядра 5.10.82 поддерживается также sysctl из Debian: <tt>kernel.unprivileged_userns_clone</tt>. Обратите внимание на то, что у него обратное поведение: для значение 1 разрешает непривелигированные USERNS, а значение 0 — запрещает.


Версия от 10:52, 29 ноября 2021

С некоторых пор в ядре доступен механизм user namespaces, в mainline ядре он доступен без ограничений непривелегированным пользователям.

К сожалению, в ядре до сих пор имеется множество подсистем не полностью адаптированных к использованию user namespaces (USERNS) и регулярно находятся связанные с ними серьёзные проблемы с безопасностью.

В ALT, как и в некоторых других дистрибутивах, в частности в Debian и Ubuntu к ядру приложены различные патчи для управления доступностью создания новых USERNS для непривелигированных пользователей. В RHEL, судя по всему, user namespaces по умолчанию выключены ещё более глобально через user.max_user_namespaces = 0. В ALT используется реализация от Kees Cook, для переключения используется sysctl kernel.userns_restrict, однако значение по умолчанию выставлено в 1 (создание USERNS непривелигированными пользователями запрещено).

Начиная с ядра 5.10.82 поддерживается также sysctl из Debian: kernel.unprivileged_userns_clone. Обратите внимание на то, что у него обратное поведение: для значение 1 разрешает непривелигированные USERNS, а значение 0 — запрещает.

При изменении значения любого из этих двух sysctl, значение другого меняется соответствующим образом. Если попытаться выставить оба значения в противоречащие значения, победит то, которое будет выставлено позже.

Это может приводить к ошибкам при запуске или использовании программ, не расчитанных на такое поведение, например: 

The SUID sandbox helper binary was found, but is not configured
correctly. Rather than run without sandboxing I'm aborting now. You
need to make sure that <путь>/chrome-sandbox is owned by root and has
mode 4755.

Для исправления можно использовать выставление SUID бита на исполняемом файле, используемом для создания USERNS (в данном случае, это chrome-sandbox из поставки стороннего приложения, предположительно основанного на Electron). При этом рекомендуется ограничить доступ к исполнению этого файла через право исполнения только для определённой группы.

Также можно глобально выключить ограничение, изменив значение sysctl.

  • временно: sysctl kernel.userns_restrict=0
  • постоянно: создать в каталоге /etc/sysctl.d файл, например с именем 50-userns.conf и следующим содержанием:
kernel.userns_restrict = 0