Userns restrict: различия между версиями
Нет описания правки |
м (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 для | В 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/ | * постоянно: | ||
** установив пакет <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