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

Материал из ALT Linux Wiki
Нет описания правки
м (fix typo + Category)
 
(не показано 7 промежуточных версий 4 участников)
Строка 1: Строка 1:
С некоторых пор в ядре доступен механизм  [https://man7.org/linux/man-pages/man7/user_namespaces.7.html user namespaces], в mainline ядре он доступен без ограничений непривелегированным пользователям.
С некоторых пор в ядре доступен механизм  [https://man7.org/linux/man-pages/man7/user_namespaces.7.html user namespaces], в mainline ядре он доступен без ограничений непривилегированным пользователям.


К сожалению, в ядре до сих пор имеется множество подсистем не полностью адаптированных к использованию user namespaces (USERNS) и регулярно находятся связанные с ними серьёзные проблемы с безопасностью.
К сожалению, в ядре до сих пор имеется множество подсистем не полностью адаптированных к использованию user namespaces (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 непривелигированными пользователями запрещено).
В 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 — запрещает.
 
При изменении значения любого из этих двух sysctl, значение другого меняется соответствующим образом. Если попытаться выставить оба значения в противоречащие значения, победит то, которое будет выставлено позже.
 
Это может приводить к ошибкам при запуске или использовании программ, не рассчитанных на такое поведение, например:
<pre>The SUID sandbox helper binary was found, but is not configured
<pre>The SUID sandbox helper binary was found, but is not configured
correctly. Rather than run without sandboxing I'm aborting now. You
correctly. Rather than run without sandboxing I'm aborting now. You
Строка 15: Строка 19:
Также можно глобально выключить ограничение, изменив значение <tt>sysctl</tt>.
Также можно глобально выключить ограничение, изменив значение <tt>sysctl</tt>.
* временно: sysctl kernel.userns_restrict=0
* временно: sysctl kernel.userns_restrict=0
* постоянно: создать в каталоге <tt>/etc/sysctld.d</tt> файл, например с именем <tt>50-userns.conf</tt> и следующим содержанием:
* постоянно:
** установив пакет <tt>sysctl-conf-userns</tt>
** или создать в каталоге <tt>/etc/sysctl.d</tt> файл, например с именем <tt>50-userns.conf</tt> и следующим содержанием:
  kernel.userns_restrict = 0
  kernel.userns_restrict = 0
{{Category navigation|title=Kernel|category=Kernel|sortkey={{SUBPAGENAME}}}}

Текущая версия от 17:02, 22 апреля 2022

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