[devel] kernel.userns_restrict

[Dmitry V. Levin]

On Thu, Nov 18, 2021 at 03:41:13PM +0300, Arseny Maslennikov wrote:
> On Thu, Nov 18, 2021 at 12:32:19PM +0000, Vladimir D. Seleznev wrote:
> > On Thu, Nov 18, 2021 at 03:21:39PM +0300, Anton Farygin wrote:
> > > А чем так плохи userns и за что мы боремся, можно рассказать ?
> 
> (Сразу скажу: я не за какую-либо из точек зрения, а за объективное
> текущее положение дел, предметный разговор и рождение истины в споре.)
> 
> > Тем, что это такой антихарденинг? Юзернс предоставляет полный набор
> > capabilities непривилегированному пользователю. Заявляется, что в нужных
> > местах в ядре есть проверки на некорневой userns, но практика
> > неоднократно показывает, что этих мест становится всё больше, с одной
> > стороны, а с другой стороны в других местах, требующих привилегий,
> > нередко наличиствуют другие огрехи безопасности, которых без userns было
> > бы невозможно эксплуатировать, т.к. их эксплуатация требовало явных
> > привилегий.
> 
> % MANWIDTH=56 man user_namespaces | head -n 30 | tail -n -20
>        User  namespaces isolate security-related iden‐
>        tifiers and attributes, in particular, user IDs
>        and  group  IDs  (see credentials(7)), the root
>        directory, keys (see keyrings(7)), and capabil‐
>        ities  (see capabilities(7)).  A process's user
>        and group IDs can be different inside and  out‐
> 
> В первом процитированном предложении лгут, получается?

Скорее wishful thinking: они хотят, чтобы так было, но оно до сих пор не
везде так.  С момента появление unprivileged userns ядерщики находят и
исправляют такие места, но конца этому нет и не предвидится.  Посмотри,
какая доля kernel exploit techniques завязана на unprivileged userns.


-- 
ldv