[devel] kernel.userns_restrict

[devel] kernel.userns_restrict

[Anton V. Boyarshinov]

Добрый день

Некоторое время назад я сделал ошибку при git rebase и потерял значение
по умолчанию для sysctl kernel.userns_restrict

Когда мне об этом сообщили, воспринял это как серьёзную проблему в
безопасности и побежал исправлять.

Но некоторое время спустя, мне открылась бездна:
[root@tower ~]# rpm -qf /lib/sysctl.d/90-bwrap.conf
bubblewrap-0.4.1-alt2.x86_64
[root@tower ~]# apt-cache whatdepends bubblewrap
bubblewrap-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014
  libwebkit2gtk-2.32.4-alt1:p10+284327.2740.7.2@1632434256
    Требует: bubblewrap >= 0.3.1
  libgnome-desktop3-40.4-alt1:p10+285934.3000.6.1@1637076523
    Требует: bubblewrap
  bubblewrap-debuginfo-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014
    Требует: bubblewrap = 0.4.1-alt2:sisyphus+276333.100.1.1
  fwupd-1.6.1-alt1:sisyphus+275599.600.6.1@1624541985
    Требует: bubblewrap
  flatpak-1.10.2-alt3:p10+284327.3300.7.2@1632434786
    Требует: bubblewrap >= 0.4.1
  nautilus-40.2-alt1:sisyphus+273636.100.1.1@1622839872
    Требует: </usr/bin/bwrap>
      bubblewrap-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014
  libflatpak-1.10.2-alt3:p10+284327.3300.7.2@1632434786
    Требует: </usr/bin/bwrap>
      bubblewrap-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014

А libgnome-desktop3 это, извините, gnome-settings-daemon и всё,
что с ним связано. Таким образом, нам в любой десктопный дистрибутив с gtk3 нечувствительно  приезжает kernel.userns_restrict=0 и я считаю, что это
блокер. Но на что вешать непонятно, ни к пуговицам, ни к рукавам претензий нет, но пиджак в целом никуда не годен.

Re: [devel] kernel.userns_restrict

[Anton V. Boyarshinov]

> 
> Но некоторое время спустя, мне открылась бездна:

Тут оказалось недокопировано:

[root@tower ~]# grep userns /lib/sysctl.d/*
/lib/sysctl.d/90-bwrap.conf:kernel.userns_restrict = 0

> [root@tower ~]# rpm -qf /lib/sysctl.d/90-bwrap.conf
> bubblewrap-0.4.1-alt2.x86_64
> [root@tower ~]# apt-cache whatdepends bubblewrap
> bubblewrap-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014
>   libwebkit2gtk-2.32.4-alt1:p10+284327.2740.7.2@1632434256
>     Требует: bubblewrap >= 0.3.1
>   libgnome-desktop3-40.4-alt1:p10+285934.3000.6.1@1637076523
>     Требует: bubblewrap
>   bubblewrap-debuginfo-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014
>     Требует: bubblewrap = 0.4.1-alt2:sisyphus+276333.100.1.1
>   fwupd-1.6.1-alt1:sisyphus+275599.600.6.1@1624541985
>     Требует: bubblewrap
>   flatpak-1.10.2-alt3:p10+284327.3300.7.2@1632434786
>     Требует: bubblewrap >= 0.4.1
>   nautilus-40.2-alt1:sisyphus+273636.100.1.1@1622839872
>     Требует: </usr/bin/bwrap>
>       bubblewrap-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014
>   libflatpak-1.10.2-alt3:p10+284327.3300.7.2@1632434786
>     Требует: </usr/bin/bwrap>
>       bubblewrap-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014
> 
> А libgnome-desktop3 это, извините, gnome-settings-daemon и всё,
> что с ним связано. Таким образом, нам в любой десктопный дистрибутив с gtk3 нечувствительно  приезжает kernel.userns_restrict=0 и я считаю, что это
> блокер. Но на что вешать непонятно, ни к пуговицам, ни к рукавам претензий нет, но пиджак в целом никуда не годен.
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] kernel.userns_restrict

[Dmitry V. Levin]

On Thu, Nov 18, 2021 at 02:36:05PM +0300, Anton V. Boyarshinov wrote:
> Добрый день
> 
> Некоторое время назад я сделал ошибку при git rebase и потерял значение
> по умолчанию для sysctl kernel.userns_restrict
> 
> Когда мне об этом сообщили, воспринял это как серьёзную проблему в
> безопасности и побежал исправлять.
> 
> Но некоторое время спустя, мне открылась бездна:
> [root@tower ~]# rpm -qf /lib/sysctl.d/90-bwrap.conf
> bubblewrap-0.4.1-alt2.x86_64
> [root@tower ~]# apt-cache whatdepends bubblewrap
> bubblewrap-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014
>   libwebkit2gtk-2.32.4-alt1:p10+284327.2740.7.2@1632434256
>     Требует: bubblewrap >= 0.3.1
>   libgnome-desktop3-40.4-alt1:p10+285934.3000.6.1@1637076523
>     Требует: bubblewrap
>   bubblewrap-debuginfo-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014
>     Требует: bubblewrap = 0.4.1-alt2:sisyphus+276333.100.1.1
>   fwupd-1.6.1-alt1:sisyphus+275599.600.6.1@1624541985
>     Требует: bubblewrap
>   flatpak-1.10.2-alt3:p10+284327.3300.7.2@1632434786
>     Требует: bubblewrap >= 0.4.1
>   nautilus-40.2-alt1:sisyphus+273636.100.1.1@1622839872
>     Требует: </usr/bin/bwrap>
>       bubblewrap-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014
>   libflatpak-1.10.2-alt3:p10+284327.3300.7.2@1632434786
>     Требует: </usr/bin/bwrap>
>       bubblewrap-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014
> 
> А libgnome-desktop3 это, извините, gnome-settings-daemon и всё,
> что с ним связано. Таким образом, нам в любой десктопный дистрибутив с gtk3 нечувствительно  приезжает kernel.userns_restrict=0 и я считаю, что это
> блокер. Но на что вешать непонятно, ни к пуговицам, ни к рукавам претензий нет, но пиджак в целом никуда не годен.

Ну что, в лучших традициях Зерга пакуем в какой-нибудь неудаляемый пакет
/lib/sysctl.d/99-zalt.conf с kernel.userns_restrict=1?


-- 
ldv

Re: [devel] kernel.userns_restrict

[Dmitry V. Levin]

On Thu, Nov 18, 2021 at 02:43:56PM +0300, Dmitry V. Levin wrote:
> On Thu, Nov 18, 2021 at 02:36:05PM +0300, Anton V. Boyarshinov wrote:
> > Добрый день
> > 
> > Некоторое время назад я сделал ошибку при git rebase и потерял значение
> > по умолчанию для sysctl kernel.userns_restrict
> > 
> > Когда мне об этом сообщили, воспринял это как серьёзную проблему в
> > безопасности и побежал исправлять.
> > 
> > Но некоторое время спустя, мне открылась бездна:
> > [root@tower ~]# rpm -qf /lib/sysctl.d/90-bwrap.conf
> > bubblewrap-0.4.1-alt2.x86_64
> > [root@tower ~]# apt-cache whatdepends bubblewrap
> > bubblewrap-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014
> >   libwebkit2gtk-2.32.4-alt1:p10+284327.2740.7.2@1632434256
> >     Требует: bubblewrap >= 0.3.1
> >   libgnome-desktop3-40.4-alt1:p10+285934.3000.6.1@1637076523
> >     Требует: bubblewrap
> >   bubblewrap-debuginfo-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014
> >     Требует: bubblewrap = 0.4.1-alt2:sisyphus+276333.100.1.1
> >   fwupd-1.6.1-alt1:sisyphus+275599.600.6.1@1624541985
> >     Требует: bubblewrap
> >   flatpak-1.10.2-alt3:p10+284327.3300.7.2@1632434786
> >     Требует: bubblewrap >= 0.4.1
> >   nautilus-40.2-alt1:sisyphus+273636.100.1.1@1622839872
> >     Требует: </usr/bin/bwrap>
> >       bubblewrap-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014
> >   libflatpak-1.10.2-alt3:p10+284327.3300.7.2@1632434786
> >     Требует: </usr/bin/bwrap>
> >       bubblewrap-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014
> > 
> > А libgnome-desktop3 это, извините, gnome-settings-daemon и всё,
> > что с ним связано. Таким образом, нам в любой десктопный дистрибутив с gtk3 нечувствительно  приезжает kernel.userns_restrict=0 и я считаю, что это
> > блокер. Но на что вешать непонятно, ни к пуговицам, ни к рукавам претензий нет, но пиджак в целом никуда не годен.
> 
> Ну что, в лучших традициях Зерга пакуем в какой-нибудь неудаляемый пакет
> /lib/sysctl.d/99-zalt.conf с kernel.userns_restrict=1?

И control userns public/restricted к нему?  Или не стоит?


-- 
ldv

Re: [devel] kernel.userns_restrict

[Mikhail Efremov]

On Thu, 18 Nov 2021 14:43:56 +0300 Dmitry V. Levin wrote:
> On Thu, Nov 18, 2021 at 02:36:05PM +0300, Anton V. Boyarshinov wrote:
> > Добрый день
> > 
> > Некоторое время назад я сделал ошибку при git rebase и потерял значение
> > по умолчанию для sysctl kernel.userns_restrict
> > 
> > Когда мне об этом сообщили, воспринял это как серьёзную проблему в
> > безопасности и побежал исправлять.
> > 
> > Но некоторое время спустя, мне открылась бездна:
> > [root@tower ~]# rpm -qf /lib/sysctl.d/90-bwrap.conf
> > bubblewrap-0.4.1-alt2.x86_64
> > [root@tower ~]# apt-cache whatdepends bubblewrap
> > bubblewrap-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014
> >   libwebkit2gtk-2.32.4-alt1:p10+284327.2740.7.2@1632434256
> >     Требует: bubblewrap >= 0.3.1
> >   libgnome-desktop3-40.4-alt1:p10+285934.3000.6.1@1637076523
> >     Требует: bubblewrap
> >   bubblewrap-debuginfo-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014
> >     Требует: bubblewrap = 0.4.1-alt2:sisyphus+276333.100.1.1
> >   fwupd-1.6.1-alt1:sisyphus+275599.600.6.1@1624541985
> >     Требует: bubblewrap
> >   flatpak-1.10.2-alt3:p10+284327.3300.7.2@1632434786
> >     Требует: bubblewrap >= 0.4.1
> >   nautilus-40.2-alt1:sisyphus+273636.100.1.1@1622839872
> >     Требует: </usr/bin/bwrap>
> >       bubblewrap-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014
> >   libflatpak-1.10.2-alt3:p10+284327.3300.7.2@1632434786
> >     Требует: </usr/bin/bwrap>
> >       bubblewrap-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014
> > 
> > А libgnome-desktop3 это, извините, gnome-settings-daemon и всё,
> > что с ним связано. Таким образом, нам в любой десктопный дистрибутив с gtk3 нечувствительно  приезжает kernel.userns_restrict=0 и я считаю, что это
> > блокер. Но на что вешать непонятно, ни к пуговицам, ни к рукавам претензий нет, но пиджак в целом никуда не годен.  
> 
> Ну что, в лучших традициях Зерга пакуем в какой-нибудь неудаляемый пакет
> /lib/sysctl.d/99-zalt.conf с kernel.userns_restrict=1?
 
Ну, для дистрибутива можно сделать инсталлер-фичу, которая подложит
/еес/sysctl.d/90-bwrap.conf.
Но вообще хотелось бы решить как-то цивилизованно. Может control в
bubblewrap?

-- 
WBR, Mikhail Efremov

Re: [devel] kernel.userns_restrict

[Dmitry V. Levin]

On Thu, Nov 18, 2021 at 03:06:41PM +0300, Mikhail Efremov wrote:
> On Thu, 18 Nov 2021 14:43:56 +0300 Dmitry V. Levin wrote:
> > On Thu, Nov 18, 2021 at 02:36:05PM +0300, Anton V. Boyarshinov wrote:
> > > Добрый день
> > > 
> > > Некоторое время назад я сделал ошибку при git rebase и потерял значение
> > > по умолчанию для sysctl kernel.userns_restrict
> > > 
> > > Когда мне об этом сообщили, воспринял это как серьёзную проблему в
> > > безопасности и побежал исправлять.
> > > 
> > > Но некоторое время спустя, мне открылась бездна:
> > > [root@tower ~]# rpm -qf /lib/sysctl.d/90-bwrap.conf
> > > bubblewrap-0.4.1-alt2.x86_64
> > > [root@tower ~]# apt-cache whatdepends bubblewrap
> > > bubblewrap-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014
> > >   libwebkit2gtk-2.32.4-alt1:p10+284327.2740.7.2@1632434256
> > >     Требует: bubblewrap >= 0.3.1
> > >   libgnome-desktop3-40.4-alt1:p10+285934.3000.6.1@1637076523
> > >     Требует: bubblewrap
> > >   bubblewrap-debuginfo-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014
> > >     Требует: bubblewrap = 0.4.1-alt2:sisyphus+276333.100.1.1
> > >   fwupd-1.6.1-alt1:sisyphus+275599.600.6.1@1624541985
> > >     Требует: bubblewrap
> > >   flatpak-1.10.2-alt3:p10+284327.3300.7.2@1632434786
> > >     Требует: bubblewrap >= 0.4.1
> > >   nautilus-40.2-alt1:sisyphus+273636.100.1.1@1622839872
> > >     Требует: </usr/bin/bwrap>
> > >       bubblewrap-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014
> > >   libflatpak-1.10.2-alt3:p10+284327.3300.7.2@1632434786
> > >     Требует: </usr/bin/bwrap>
> > >       bubblewrap-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014
> > > 
> > > А libgnome-desktop3 это, извините, gnome-settings-daemon и всё,
> > > что с ним связано. Таким образом, нам в любой десктопный дистрибутив с gtk3 нечувствительно  приезжает kernel.userns_restrict=0 и я считаю, что это
> > > блокер. Но на что вешать непонятно, ни к пуговицам, ни к рукавам претензий нет, но пиджак в целом никуда не годен.  
> > 
> > Ну что, в лучших традициях Зерга пакуем в какой-нибудь неудаляемый пакет
> > /lib/sysctl.d/99-zalt.conf с kernel.userns_restrict=1?
>  
> Ну, для дистрибутива можно сделать инсталлер-фичу, которая подложит
> /еес/sysctl.d/90-bwrap.conf.

Дистрибутив должен ограничиваться /lib/sysctl.d/,
поскольку /etc/sysctl.d/ зарезервирован для администратора.

> Но вообще хотелось бы решить как-то цивилизованно. Может control в
> bubblewrap?

Я слышал, что bubblewrap без userns бесполезна.  Но проблема в том, что
эта хрень вытягивается по зависимостям и компрометирует даже те системы,
в которых не используется.  Получается, что это вопрос настройки не
отдельной хрени под названием bubblewrap, а всей системы целиком.


-- 
ldv

Re: [devel] kernel.userns_restrict

[Anton Farygin]

On 18.11.2021 15:12, Dmitry V. Levin wrote:
> On Thu, Nov 18, 2021 at 03:06:41PM +0300, Mikhail Efremov wrote:
>> On Thu, 18 Nov 2021 14:43:56 +0300 Dmitry V. Levin wrote:
>>> On Thu, Nov 18, 2021 at 02:36:05PM +0300, Anton V. Boyarshinov wrote:
>>>> Добрый день
>>>>
>>>> Некоторое время назад я сделал ошибку при git rebase и потерял значение
>>>> по умолчанию для sysctl kernel.userns_restrict
>>>>
>>>> Когда мне об этом сообщили, воспринял это как серьёзную проблему в
>>>> безопасности и побежал исправлять.
>>>>
>>>> Но некоторое время спустя, мне открылась бездна:
>>>> [root@tower ~]# rpm -qf /lib/sysctl.d/90-bwrap.conf
>>>> bubblewrap-0.4.1-alt2.x86_64
>>>> [root@tower ~]# apt-cache whatdepends bubblewrap
>>>> bubblewrap-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014
>>>>    libwebkit2gtk-2.32.4-alt1:p10+284327.2740.7.2@1632434256
>>>>      Требует: bubblewrap >= 0.3.1
>>>>    libgnome-desktop3-40.4-alt1:p10+285934.3000.6.1@1637076523
>>>>      Требует: bubblewrap
>>>>    bubblewrap-debuginfo-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014
>>>>      Требует: bubblewrap = 0.4.1-alt2:sisyphus+276333.100.1.1
>>>>    fwupd-1.6.1-alt1:sisyphus+275599.600.6.1@1624541985
>>>>      Требует: bubblewrap
>>>>    flatpak-1.10.2-alt3:p10+284327.3300.7.2@1632434786
>>>>      Требует: bubblewrap >= 0.4.1
>>>>    nautilus-40.2-alt1:sisyphus+273636.100.1.1@1622839872
>>>>      Требует: </usr/bin/bwrap>
>>>>        bubblewrap-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014
>>>>    libflatpak-1.10.2-alt3:p10+284327.3300.7.2@1632434786
>>>>      Требует: </usr/bin/bwrap>
>>>>        bubblewrap-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014
>>>>
>>>> А libgnome-desktop3 это, извините, gnome-settings-daemon и всё,
>>>> что с ним связано. Таким образом, нам в любой десктопный дистрибутив с gtk3 нечувствительно  приезжает kernel.userns_restrict=0 и я считаю, что это
>>>> блокер. Но на что вешать непонятно, ни к пуговицам, ни к рукавам претензий нет, но пиджак в целом никуда не годен.
>>> Ну что, в лучших традициях Зерга пакуем в какой-нибудь неудаляемый пакет
>>> /lib/sysctl.d/99-zalt.conf с kernel.userns_restrict=1?
>>   
>> Ну, для дистрибутива можно сделать инсталлер-фичу, которая подложит
>> /еес/sysctl.d/90-bwrap.conf.
> Дистрибутив должен ограничиваться /lib/sysctl.d/,
> поскольку /etc/sysctl.d/ зарезервирован для администратора.
>
>> Но вообще хотелось бы решить как-то цивилизованно. Может control в
>> bubblewrap?
> Я слышал, что bubblewrap без userns бесполезна.  Но проблема в том, что
> эта хрень вытягивается по зависимостям и компрометирует даже те системы,
> в которых не используется.  Получается, что это вопрос настройки не
> отдельной хрени под названием bubblewrap, а всей системы целиком.

Делайте что хотите, но в результате bubblewrap должен остаться рабочим в 
установленной системе.

Re: [devel] kernel.userns_restrict

[Dmitry V. Levin]

On Thu, Nov 18, 2021 at 03:15:53PM +0300, Anton Farygin wrote:
> On 18.11.2021 15:12, Dmitry V. Levin wrote:
> > On Thu, Nov 18, 2021 at 03:06:41PM +0300, Mikhail Efremov wrote:
> >> On Thu, 18 Nov 2021 14:43:56 +0300 Dmitry V. Levin wrote:
> >>> On Thu, Nov 18, 2021 at 02:36:05PM +0300, Anton V. Boyarshinov wrote:
> >>>> Добрый день
> >>>>
> >>>> Некоторое время назад я сделал ошибку при git rebase и потерял значение
> >>>> по умолчанию для sysctl kernel.userns_restrict
> >>>>
> >>>> Когда мне об этом сообщили, воспринял это как серьёзную проблему в
> >>>> безопасности и побежал исправлять.
> >>>>
> >>>> Но некоторое время спустя, мне открылась бездна:
> >>>> [root@tower ~]# rpm -qf /lib/sysctl.d/90-bwrap.conf
> >>>> bubblewrap-0.4.1-alt2.x86_64
> >>>> [root@tower ~]# apt-cache whatdepends bubblewrap
> >>>> bubblewrap-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014
> >>>>    libwebkit2gtk-2.32.4-alt1:p10+284327.2740.7.2@1632434256
> >>>>      Требует: bubblewrap >= 0.3.1
> >>>>    libgnome-desktop3-40.4-alt1:p10+285934.3000.6.1@1637076523
> >>>>      Требует: bubblewrap
> >>>>    bubblewrap-debuginfo-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014
> >>>>      Требует: bubblewrap = 0.4.1-alt2:sisyphus+276333.100.1.1
> >>>>    fwupd-1.6.1-alt1:sisyphus+275599.600.6.1@1624541985
> >>>>      Требует: bubblewrap
> >>>>    flatpak-1.10.2-alt3:p10+284327.3300.7.2@1632434786
> >>>>      Требует: bubblewrap >= 0.4.1
> >>>>    nautilus-40.2-alt1:sisyphus+273636.100.1.1@1622839872
> >>>>      Требует: </usr/bin/bwrap>
> >>>>        bubblewrap-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014
> >>>>    libflatpak-1.10.2-alt3:p10+284327.3300.7.2@1632434786
> >>>>      Требует: </usr/bin/bwrap>
> >>>>        bubblewrap-0.4.1-alt2:sisyphus+276333.100.1.1@1624975014
> >>>>
> >>>> А libgnome-desktop3 это, извините, gnome-settings-daemon и всё,
> >>>> что с ним связано. Таким образом, нам в любой десктопный дистрибутив с gtk3 нечувствительно  приезжает kernel.userns_restrict=0 и я считаю, что это
> >>>> блокер. Но на что вешать непонятно, ни к пуговицам, ни к рукавам претензий нет, но пиджак в целом никуда не годен.
> >>> Ну что, в лучших традициях Зерга пакуем в какой-нибудь неудаляемый пакет
> >>> /lib/sysctl.d/99-zalt.conf с kernel.userns_restrict=1?
> >>   
> >> Ну, для дистрибутива можно сделать инсталлер-фичу, которая подложит
> >> /еес/sysctl.d/90-bwrap.conf.
> > Дистрибутив должен ограничиваться /lib/sysctl.d/,
> > поскольку /etc/sysctl.d/ зарезервирован для администратора.
> >
> >> Но вообще хотелось бы решить как-то цивилизованно. Может control в
> >> bubblewrap?
> > Я слышал, что bubblewrap без userns бесполезна.  Но проблема в том, что
> > эта хрень вытягивается по зависимостям и компрометирует даже те системы,
> > в которых не используется.  Получается, что это вопрос настройки не
> > отдельной хрени под названием bubblewrap, а всей системы целиком.
> 
> Делайте что хотите, но в результате bubblewrap должен остаться рабочим в 
> установленной системе.

Я считаю безопасность ОС важнее, чем работоспособность bubblewrap.
Если компромисса не найдётся, я без колебаний пожертвую bubblewrap'ом.


-- 
ldv

Re: [devel] kernel.userns_restrict

[Anton Farygin]

On 18.11.2021 15:18, Dmitry V. Levin wrote:
>> Делайте что хотите, но в результате bubblewrap должен остаться рабочим в
>> установленной системе.
> Я считаю безопасность ОС важнее, чем работоспособность bubblewrap.
> Если компромисса не найдётся, я без колебаний пожертвую bubblewrap'ом.

если компромисса не найдётся я без колебаний перейду на другой дистрибутив.

Потому что без bubblerwap у нас будет сломан целый слой, его использующий.

Лично мне важен работоспособный flatpack и opam.


А чем так плохи userns и за что мы боремся, можно рассказать ?

Re: [devel] kernel.userns_restrict

[Vladimir D. Seleznev]

On Thu, Nov 18, 2021 at 03:21:39PM +0300, Anton Farygin wrote:
> On 18.11.2021 15:18, Dmitry V. Levin wrote:
> >> Делайте что хотите, но в результате bubblewrap должен остаться рабочим в
> >> установленной системе.
> > Я считаю безопасность ОС важнее, чем работоспособность bubblewrap.
> > Если компромисса не найдётся, я без колебаний пожертвую bubblewrap'ом.
> 
> если компромисса не найдётся я без колебаний перейду на другой дистрибутив.
> 
> Потому что без bubblerwap у нас будет сломан целый слой, его использующий.
> 
> Лично мне важен работоспособный flatpack и opam.
> 
> 
> А чем так плохи userns и за что мы боремся, можно рассказать ?

Тем, что это такой антихарденинг? Юзернс предоставляет полный набор
capabilities непривилегированному пользователю. Заявляется, что в нужных
местах в ядре есть проверки на некорневой userns, но практика
неоднократно показывает, что этих мест становится всё больше, с одной
стороны, а с другой стороны в других местах, требующих привилегий,
нередко наличиствуют другие огрехи безопасности, которых без userns было
бы невозможно эксплуатировать, т.к. их эксплуатация требовало явных
привилегий.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] kernel.userns_restrict

[Anton Farygin]

On 18.11.2021 14:37, Anton V. Boyarshinov wrote:
>> Но некоторое время спустя, мне открылась бездна:
> Тут оказалось недокопировано:
>
> [root@tower ~]# grep userns/lib/sysctl.d/*
> /lib/sysctl.d/90-bwrap.conf:kernel.userns_restrict = 0
>
Это, кстати, может быть и ошибкой - нужно что бы кто-то разобрался, надо 
ли действительно современному bubblewrap такое поведение ядра.

Re: [devel] kernel.userns_restrict

[Dmitry V. Levin]

On Thu, Nov 18, 2021 at 03:21:39PM +0300, Anton Farygin wrote:
> On 18.11.2021 15:18, Dmitry V. Levin wrote:
> >> Делайте что хотите, но в результате bubblewrap должен остаться рабочим в
> >> установленной системе.
> > Я считаю безопасность ОС важнее, чем работоспособность bubblewrap.
> > Если компромисса не найдётся, я без колебаний пожертвую bubblewrap'ом.
> 
> если компромисса не найдётся я без колебаний перейду на другой дистрибутив.
> 
> Потому что без bubblerwap у нас будет сломан целый слой, его использующий.
> 
> Лично мне важен работоспособный flatpack и opam.

Ну и включай себе общедоступный userns, это твоё личное дело.  Я не
понимаю, каким образом у тебя вышло, что твоё желание использовать
какие-то фичи должно приводить к тому, что все остальные должны включать
себе целый класс уязвимостей.


-- 
ldv

Re: [devel] kernel.userns_restrict

[Anton Farygin]

On 18.11.2021 15:34, Dmitry V. Levin wrote:
> On Thu, Nov 18, 2021 at 03:21:39PM +0300, Anton Farygin wrote:
>> On 18.11.2021 15:18, Dmitry V. Levin wrote:
>>>> Делайте что хотите, но в результате bubblewrap должен остаться рабочим в
>>>> установленной системе.
>>> Я считаю безопасность ОС важнее, чем работоспособность bubblewrap.
>>> Если компромисса не найдётся, я без колебаний пожертвую bubblewrap'ом.
>> если компромисса не найдётся я без колебаний перейду на другой дистрибутив.
>>
>> Потому что без bubblerwap у нас будет сломан целый слой, его использующий.
>>
>> Лично мне важен работоспособный flatpack и opam.
> Ну и включай себе общедоступный userns, это твоё личное дело.  Я не
> понимаю, каким образом у тебя вышло, что твоё желание использовать
> какие-то фичи должно приводить к тому, что все остальные должны включать
> себе целый класс уязвимостей.

См. выше - мне важно что бы  у меня после обновления ничего не сломалось.

Те, кто хочет жить в изолированном виде без целого класса уязвимостей - 
не будут ставить себе потенциально уязвимый bubblewrap.

Ну и на самом деле я написал в другом письме, что bubblewrap вроде как 
умеет работать без userns, но было бы неплохо, если бы его ментейнер (и 
автор этого самого /lib/sysctl.d/90-bwrap.conf
) с этим разобрался - может ли и если да, то какой ценой.

Re: [devel] kernel.userns_restrict

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 1918 bytes --]

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‐

В первом процитированном предложении лгут, получается?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] kernel.userns_restrict

[Dmitry V. Levin]

On Thu, Nov 18, 2021 at 03:40:34PM +0300, Anton Farygin wrote:
> On 18.11.2021 15:34, Dmitry V. Levin wrote:
> > On Thu, Nov 18, 2021 at 03:21:39PM +0300, Anton Farygin wrote:
> >> On 18.11.2021 15:18, Dmitry V. Levin wrote:
> >>>> Делайте что хотите, но в результате bubblewrap должен остаться рабочим в
> >>>> установленной системе.
> >>> Я считаю безопасность ОС важнее, чем работоспособность bubblewrap.
> >>> Если компромисса не найдётся, я без колебаний пожертвую bubblewrap'ом.
> >> если компромисса не найдётся я без колебаний перейду на другой дистрибутив.
> >>
> >> Потому что без bubblerwap у нас будет сломан целый слой, его использующий.
> >>
> >> Лично мне важен работоспособный flatpack и opam.
> > Ну и включай себе общедоступный userns, это твоё личное дело.  Я не
> > понимаю, каким образом у тебя вышло, что твоё желание использовать
> > какие-то фичи должно приводить к тому, что все остальные должны включать
> > себе целый класс уязвимостей.
> 
> См. выше - мне важно чтобы у меня после обновления ничего не сломалось.
> 
> Те, кто хочет жить в изолированном виде без целого класса уязвимостей - 
> не будут ставить себе потенциально уязвимый bubblewrap.

Так проблема именно в том, что bubblewrap вытягивается по зависимостям почти
у всех, хотя используется далеко не всеми.

> Ну и на самом деле я написал в другом письме, что bubblewrap вроде как 
> умеет работать без userns, но было бы неплохо, если бы его ментейнер (и 
> автор этого самого /lib/sysctl.d/90-bwrap.conf
> ) с этим разобрался - может ли и если да, то какой ценой.

Наверное, что-нибудь перестанет работать.


-- 
ldv

Re: [devel] kernel.userns_restrict

[Anton Farygin]

On 18.11.2021 15:44, Dmitry V. Levin wrote:
> On Thu, Nov 18, 2021 at 03:40:34PM +0300, Anton Farygin wrote:
>> On 18.11.2021 15:34, Dmitry V. Levin wrote:
>>> On Thu, Nov 18, 2021 at 03:21:39PM +0300, Anton Farygin wrote:
>>>> On 18.11.2021 15:18, Dmitry V. Levin wrote:
>>>>>> Делайте что хотите, но в результате bubblewrap должен остаться рабочим в
>>>>>> установленной системе.
>>>>> Я считаю безопасность ОС важнее, чем работоспособность bubblewrap.
>>>>> Если компромисса не найдётся, я без колебаний пожертвую bubblewrap'ом.
>>>> если компромисса не найдётся я без колебаний перейду на другой дистрибутив.
>>>>
>>>> Потому что без bubblerwap у нас будет сломан целый слой, его использующий.
>>>>
>>>> Лично мне важен работоспособный flatpack и opam.
>>> Ну и включай себе общедоступный userns, это твоё личное дело.  Я не
>>> понимаю, каким образом у тебя вышло, что твоё желание использовать
>>> какие-то фичи должно приводить к тому, что все остальные должны включать
>>> себе целый класс уязвимостей.
>> См. выше - мне важно чтобы у меня после обновления ничего не сломалось.
>>
>> Те, кто хочет жить в изолированном виде без целого класса уязвимостей -
>> не будут ставить себе потенциально уязвимый bubblewrap.
> Так проблема именно в том, что bubblewrap вытягивается по зависимостям почти
> у всех, хотя используется далеко не всеми.
Так может быть решать именно эту проблему ?
>
>> Ну и на самом деле я написал в другом письме, что bubblewrap вроде как
>> умеет работать без userns, но было бы неплохо, если бы его ментейнер (и
>> автор этого самого /lib/sysctl.d/90-bwrap.conf
>> ) с этим разобрался - может ли и если да, то какой ценой.
> Наверное, что-нибудь перестанет работать.

Было бы неплохо, если бы кто-то разобрался. У меня сейчас на это времени 
совсем нет, к сожалению.

Re: [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

Re: [devel] kernel.userns_restrict

[Anton Farygin]

On 18.11.2021 15:47, Anton Farygin wrote:
>> Так проблема именно в том, что bubblewrap вытягивается по 
>> зависимостям почти
>> у всех, хотя используется далеко не всеми.
> Так может быть решать именно эту проблему ? 

Я к тому, что opam, например, не зависит. Просто не работает ;)

Re: [devel] kernel.userns_restrict

[Alexey Sheplyakov]

Здравствуйте!

On 18.11.2021 15:36, Anton V. Boyarshinov wrote:
> Добрый день
> 
> Некоторое время назад я сделал ошибку при git rebase и потерял значение
> по умолчанию для sysctl kernel.userns_restrict
> 
> Когда мне об этом сообщили, воспринял это как серьёзную проблему в
> безопасности и побежал исправлять.

С той же степенью обоснованности "серьёзной проблемой" является наличие сетевых интерфейсов.
И отключить их по умолчанию для пущей безопасности. А можно и вообще компьютер не включать.
Так 100% ни один злодей не пройдёт.

> Таким образом, нам в любой десктопный дистрибутив с gtk3 нечувствительно  приезжает kernel.userns_restrict=0

И очень хорошо, что хоть каким-то дистрибутивом можно прямо из коробки пользоваться.
А не чинить сломанное излишне тревожными гражданами.

Re: [devel] kernel.userns_restrict

[Vladimir D. Seleznev]

On Fri, Nov 19, 2021 at 05:41:54PM +0400, Alexey Sheplyakov wrote:
> Здравствуйте!
> 
> On 18.11.2021 15:36, Anton V. Boyarshinov wrote:
> > Добрый день
> > 
> > Некоторое время назад я сделал ошибку при git rebase и потерял значение
> > по умолчанию для sysctl kernel.userns_restrict
> > 
> > Когда мне об этом сообщили, воспринял это как серьёзную проблему в
> > безопасности и побежал исправлять.
> 
> С той же степенью обоснованности "серьёзной проблемой" является наличие сетевых интерфейсов.

Ну, например я рассматриваю как проблему наличие модулей сетевых
интерфейсов в кернелспейсе, но, к сожалению, в отличие от вышеописанной
проблемы её сложнее исправить.

> И отключить их по умолчанию для пущей безопасности. А можно и вообще компьютер не включать.
> Так 100% ни один злодей не пройдёт.
> 
> > Таким образом, нам в любой десктопный дистрибутив с gtk3 нечувствительно  приезжает kernel.userns_restrict=0
> 
> И очень хорошо, что хоть каким-то дистрибутивом можно прямо из коробки пользоваться.
> А не чинить сломанное излишне тревожными гражданами.

Может тогда стоит пользоваться дистрибутивами, которые работают?

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] kernel.userns_restrict

[Anton V. Boyarshinov]

В Thu, 18 Nov 2021 15:01:49 +0300
"Dmitry V. Levin" <ldv@altlinux.org> пишет:

> > Ну что, в лучших традициях Зерга пакуем в какой-нибудь неудаляемый пакет
> > /lib/sysctl.d/99-zalt.conf с kernel.userns_restrict=1?  
> 
> И control userns public/restricted к нему?  Или не стоит?

Более мягкое решение с control:
http://git.altlinux.org/tasks/290042/

Re: [devel] kernel.userns_restrict

[mikhailnov]

18.11.2021 15:47, Anton Farygin пишет:
> On 18.11.2021 15:44, Dmitry V. Levin wrote:
>> On Thu, Nov 18, 2021 at 03:40:34PM +0300, Anton Farygin wrote:
>>> On 18.11.2021 15:34, Dmitry V. Levin wrote:
>>>> On Thu, Nov 18, 2021 at 03:21:39PM +0300, Anton Farygin wrote:
>>>>> On 18.11.2021 15:18, Dmitry V. Levin wrote:
>>>>>>> Делайте что хотите, но в результате bubblewrap должен остаться рабочим в
>>>>>>> установленной системе.
>>>>>> Я считаю безопасность ОС важнее, чем работоспособность bubblewrap.
>>>>>> Если компромисса не найдётся, я без колебаний пожертвую bubblewrap'ом.
>>>>> если компромисса не найдётся я без колебаний перейду на другой дистрибутив.
>>>>>
>>>>> Потому что без bubblerwap у нас будет сломан целый слой, его использующий.
>>>>>
>>>>> Лично мне важен работоспособный flatpack и opam.
>>>> Ну и включай себе общедоступный userns, это твоё личное дело.  Я не
>>>> понимаю, каким образом у тебя вышло, что твоё желание использовать
>>>> какие-то фичи должно приводить к тому, что все остальные должны включать
>>>> себе целый класс уязвимостей.
>>> См. выше - мне важно чтобы у меня после обновления ничего не сломалось.
>>>
>>> Те, кто хочет жить в изолированном виде без целого класса уязвимостей -
>>> не будут ставить себе потенциально уязвимый bubblewrap.
>> Так проблема именно в том, что bubblewrap вытягивается по зависимостям почти
>> у всех, хотя используется далеко не всеми.
Насколько помню, библиотеки какого-то из webkit-ов запускают утилиту bwrap.

Re: [devel] kernel.userns_restrict

[Vladimir Didenko]

чт, 18 нояб. 2021 г. в 14:36, Anton V. Boyarshinov:
>
> Добрый день
>
> Некоторое время назад я сделал ошибку при git rebase и потерял значение
> по умолчанию для sysctl kernel.userns_restrict
>
> Когда мне об этом сообщили, воспринял это как серьёзную проблему в
> безопасности и побежал исправлять.
>
> что с ним связано. Таким образом, нам в любой десктопный дистрибутив с gtk3 нечувствительно  приезжает kernel.userns_restrict=0 и я считаю, что это
> блокер. Но на что вешать непонятно, ни к пуговицам, ни к рукавам претензий нет, но пиджак в целом никуда не годен.

Добрый вечер.

Я тут сегодня после обновления обнаружил, что у меня Mattermost не
запускается с вводящей в заблуждение ошибкой вроде

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.

Хорошо, что я читаю devel, и понял, что причина это удаление конфига
из bubblewrap, но как быть обычному пользователю? Может, авторы
изменений хотя бы страничку на нашей Вики оформят? А еще, мы точно
уверены, что дефолт, при котором программы без проблем работающие на
Ubuntu/Fedora/Arch у нас просто не запускаются это хороший дефолт?

И, на всякий, ссылка на багтрекер электрона -
https://github.com/electron/electron/issues/17972. Можно посмотреть на
количество дупликатов, чтобы понять, что у пользователей отвалится
куча приложений.

-- 
С уважением,
Владимир.

Re: [devel] kernel.userns_restrict

[Vladimir D. Seleznev]

On Wed, Nov 24, 2021 at 06:52:33PM +0300, Vladimir Didenko wrote:
> чт, 18 нояб. 2021 г. в 14:36, Anton V. Boyarshinov:
> >
> > Добрый день
> >
> > Некоторое время назад я сделал ошибку при git rebase и потерял значение
> > по умолчанию для sysctl kernel.userns_restrict
> >
> > Когда мне об этом сообщили, воспринял это как серьёзную проблему в
> > безопасности и побежал исправлять.
> >
> > что с ним связано. Таким образом, нам в любой десктопный дистрибутив с gtk3 нечувствительно  приезжает kernel.userns_restrict=0 и я считаю, что это
> > блокер. Но на что вешать непонятно, ни к пуговицам, ни к рукавам претензий нет, но пиджак в целом никуда не годен.
> 
> Добрый вечер.
> 
> Я тут сегодня после обновления обнаружил, что у меня Mattermost не
> запускается с вводящей в заблуждение ошибкой вроде
> 
> 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.
> 
> Хорошо, что я читаю devel, и понял, что причина это удаление конфига
> из bubblewrap, но как быть обычному пользователю?

Там же написано: make sure that ... chrome-sandbox is owned by root and
has mode 4755. В Сизифе тот же chromium упакован так, что на
chrome-sandbox установлен suid-бит.

> Может, авторы изменений хотя бы страничку на нашей Вики оформят? А
> еще, мы точно уверены, что дефолт, при котором программы без проблем
> работающие на Ubuntu/Fedora/Arch у нас просто не запускаются это
> хороший дефолт?

Я за secure by default.

> И, на всякий, ссылка на багтрекер электрона -
> https://github.com/electron/electron/issues/17972. Можно посмотреть на
> количество дупликатов, чтобы понять, что у пользователей отвалится
> куча приложений.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] kernel.userns_restrict

[Vladimir Didenko]

ср, 24 нояб. 2021 г. в 19:03, Vladimir D. Seleznev:
>
>
> Там же написано: make sure that ... chrome-sandbox is owned by root and
> has mode 4755. В Сизифе тот же chromium упакован так, что на
> chrome-sandbox установлен suid-бит.

Я suid бит на Mattermost в здравом уме ставить не буду.

> Я за secure by default.

Это спорно, что сделанное изменение сделает пользователю более
безопасно. Тот же Brave без user namespaces просто выключает sandbox -
где тут безопасность? Если верить

https://lists.debian.org/debian-kernel/2020/03/msg00237.html

то Firefox в этом случае тоже тихо выключит sandbox. Это тоже
безопаснее для пользователя?

-- 
С уважением,
Владимир.

Re: [devel] kernel.userns_restrict

[Vladimir D. Seleznev]

On Wed, Nov 24, 2021 at 07:08:41PM +0300, Vladimir Didenko wrote:
> ср, 24 нояб. 2021 г. в 19:03, Vladimir D. Seleznev:
> >
> >
> > Там же написано: make sure that ... chrome-sandbox is owned by root and
> > has mode 4755. В Сизифе тот же chromium упакован так, что на
> > chrome-sandbox установлен suid-бит.
> 
> Я suid бит на Mattermost в здравом уме ставить не буду.

Дозволенный userns для непревилегированных пользователей — всё равно,
что suid на каждый executable в системе. Я, конечно, немного утрирую и
предвзят, но практика показывает, что userns — это не подходящий
механизм безопасности.

> > Я за secure by default.
> 
> Это спорно, что сделанное изменение сделает пользователю более
> безопасно. Тот же Brave без user namespaces просто выключает sandbox -
> где тут безопасность? Если верить
> 
> https://lists.debian.org/debian-kernel/2020/03/msg00237.html
> 
> то Firefox в этом случае тоже тихо выключит sandbox. Это тоже
> безопаснее для пользователя?

Так и же без suid-бита brave просто молча выключает sandbox. Если
выставить suid-бит, то будет сендбокситься.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] kernel.userns_restrict

[Aleksey Novodvorsky]

ср, 24 нояб. 2021 г. в 19:03, Vladimir D. Seleznev <vseleznv@altlinux.org>:
>
> On Wed, Nov 24, 2021 at 06:52:33PM +0300, Vladimir Didenko wrote:
> > чт, 18 нояб. 2021 г. в 14:36, Anton V. Boyarshinov:
> > >
> > > Добрый день
> > >
> > > Некоторое время назад я сделал ошибку при git rebase и потерял значение
> > > по умолчанию для sysctl kernel.userns_restrict
> > >
> > > Когда мне об этом сообщили, воспринял это как серьёзную проблему в
> > > безопасности и побежал исправлять.
> > >
> > > что с ним связано. Таким образом, нам в любой десктопный дистрибутив с gtk3 нечувствительно  приезжает kernel.userns_restrict=0 и я считаю, что это
> > > блокер. Но на что вешать непонятно, ни к пуговицам, ни к рукавам претензий нет, но пиджак в целом никуда не годен.
> >
> > Добрый вечер.
> >
> > Я тут сегодня после обновления обнаружил, что у меня Mattermost не
> > запускается с вводящей в заблуждение ошибкой вроде
> >
> > 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.
> >
> > Хорошо, что я читаю devel, и понял, что причина это удаление конфига
> > из bubblewrap, но как быть обычному пользователю?
>
> Там же написано: make sure that ... chrome-sandbox is owned by root and
> has mode 4755. В Сизифе тот же chromium упакован так, что на
> chrome-sandbox установлен suid-бит.
>
> > Может, авторы изменений хотя бы страничку на нашей Вики оформят? А
> > еще, мы точно уверены, что дефолт, при котором программы без проблем
> > работающие на Ubuntu/Fedora/Arch у нас просто не запускаются это
> > хороший дефолт?
>
> Я за secure by default.

Я тоже, но умолчания все же определяет релиз-менеджер каждого продукта.
Замечу также, что админы очень часто меняют наши умалчиваемые
настройки  и далеко не в сторону защищенности. Но это их выбор.
Нужен, наверное, также удобный и документированный способ выбора.

Rgrds, Алексей

>
> > И, на всякий, ссылка на багтрекер электрона -
> > https://github.com/electron/electron/issues/17972. Можно посмотреть на
> > количество дупликатов, чтобы понять, что у пользователей отвалится
> > куча приложений.
>
> --
>    WBR,
>    Vladimir D. Seleznev
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] kernel.userns_restrict

[Anton V. Boyarshinov]

В Wed, 24 Nov 2021 18:52:33 +0300
Vladimir Didenko <vladimir.didenko@gmail.com> пишет:

> Хорошо, что я читаю devel, и понял, что причина это удаление конфига
> из bubblewrap, но как быть обычному пользователю?

Вообще говоря, если какие-то программы работали только благодаря
наличию этого конфига в совершенно для них постороннем пакете, это было
неправильно. И то, что мы теперь знаем об этом, вообще говоря благо.
Что с этим благом делать -- другой вопрос.

А я-то всё удивлялся, почему на выключение unpriv userns по умолчанию
ни разу не поступало ни одной жалобы! Правда, удивлялся я недостаточно,
чтоб изучить почему именно жалобы не поступают, а зря.

> Может, авторы
> изменений хотя бы страничку на нашей Вики оформят? А еще, мы точно
> уверены, что дефолт, при котором программы без проблем работающие на
> Ubuntu/Fedora/Arch у нас просто не запускаются это хороший дефолт?

Видимо, всё-таки надо делать более/менее удобный переключатель в
дополнение к возможности написать что-нибудь в /etc/sysctl.d

Re: [devel] kernel.userns_restrict

[Anton V. Boyarshinov]

В Wed, 24 Nov 2021 19:08:41 +0300
Vladimir Didenko <vladimir.didenko@gmail.com> пишет:

> > Там же написано: make sure that ... chrome-sandbox is owned by root and
> > has mode 4755. В Сизифе тот же chromium упакован так, что на
> > chrome-sandbox установлен suid-бит.  
> 
> Я suid бит на Mattermost в здравом уме ставить не буду.

Так не на весь же, а не helper...

Re: [devel] kernel.userns_restrict

[Yuri Sedunov]

В Чт, 18/11/2021 в 14:36 +0300, Anton V. Boyarshinov пишет:
> Добрый день
> 
> Некоторое время назад я сделал ошибку при git rebase и потерял значение
> по умолчанию для sysctl kernel.userns_restrict
> 
> Когда мне об этом сообщили, воспринял это как серьёзную проблему в
> безопасности и побежал исправлять.

В каком un-def это было "исправлено"? По ченджлогу не видно.
* Mon Nov 22 2021 Kernel Bot <kernelbot@altlinux.org> 1:5.14.21-alt1
- v5.14.21

* Fri Nov 19 2021 Kernel Bot <kernelbot@altlinux.org> 1:5.14.20-alt1
- v5.14.20  (Fixes: CVE-2021-3640)

* Sat Nov 13 2021 Kernel Bot <kernelbot@altlinux.org> 1:5.14.18-alt1
- v5.14.18

* Mon Nov 08 2021 Kernel Bot <kernelbot@altlinux.org> 1:5.14.17-alt1
- v5.14.17

-- 
Yuri N. Sedunov

Re: [devel] kernel.userns_restrict

[Anton V. Boyarshinov]

В Wed, 24 Nov 2021 18:52:33 +0300
Vladimir Didenko <vladimir.didenko@gmail.com> пишет:

>  Может, авторы
> изменений хотя бы страничку на нашей Вики оформят?

https://www.altlinux.org/Userns_restrict

> А еще, мы точно
> уверены, что дефолт, при котором программы без проблем работающие на
> Ubuntu/Fedora/Arch у нас просто не запускаются это хороший дефолт?

Ну, в RHEL, насколько я понимаю, дефолт такой же (хотя механизм
реализации другой). Но это, мягко говоря, не главный критерий хорошего
дефолта. Вот у нас tcb по дефолту, нет чтоб "как у всех"...

Re: [devel] kernel.userns_restrict

[Sergey V Turchin]

On Friday, 26 November 2021 10:55:09 MSK Anton V wrote:
> В Wed, 24 Nov 2021 18:52:33 +0300
> 
> Vladimir Didenko <vladimir.didenko@gmail.com> пишет:
> >  Может, авторы
> > 
> > изменений хотя бы страничку на нашей Вики оформят?
> 
> https://www.altlinux.org/Userns_restrict
Там написано, что значение и 0 и 1 -- "глобально вЫключить ограничение".

-- 
Regards, Sergey.

Re: [devel] kernel.userns_restrict

[Anton V. Boyarshinov]

В Fri, 26 Nov 2021 10:29:37 +0300
Yuri Sedunov <aris@altlinux.org> пишет:

> > Некоторое время назад я сделал ошибку при git rebase и потерял значение
> > по умолчанию для sysctl kernel.userns_restrict
> > 
> > Когда мне об этом сообщили, воспринял это как серьёзную проблему в
> > безопасности и побежал исправлять.  
> 
> В каком un-def это было "исправлено"? 

в 5.14.18-alt1

> По ченджлогу не видно.
> * Mon Nov 22 2021 Kernel Bot <kernelbot@altlinux.org> 1:5.14.21-alt1
> - v5.14.21
> 
> * Fri Nov 19 2021 Kernel Bot <kernelbot@altlinux.org> 1:5.14.20-alt1
> - v5.14.20  (Fixes: CVE-2021-3640)
> 
> * Sat Nov 13 2021 Kernel Bot <kernelbot@altlinux.org> 1:5.14.18-alt1
> - v5.14.18
> 
> * Mon Nov 08 2021 Kernel Bot <kernelbot@altlinux.org> 1:5.14.17-alt1
> - v5.14.17
> 

Re: [devel] kernel.userns_restrict

[Anton Farygin]

On 26.11.2021 11:33, Anton V. Boyarshinov wrote:
> В Fri, 26 Nov 2021 10:29:37 +0300
> Yuri Sedunov<aris@altlinux.org>  пишет:
>
>>> Некоторое время назад я сделал ошибку при git rebase и потерял значение
>>> по умолчанию для sysctl kernel.userns_restrict
>>>
>>> Когда мне об этом сообщили, воспринял это как серьёзную проблему в
>>> безопасности и побежал исправлять.
>> В каком un-def это было "исправлено"?
> в 5.14.18-alt1
>
Большая просьба отражать такие изменения в changelog.

Re: [devel] kernel.userns_restrict

[Yuri Sedunov]

В Пт, 26/11/2021 в 11:33 +0300, Anton V. Boyarshinov пишет:
> В Fri, 26 Nov 2021 10:29:37 +0300
> Yuri Sedunov <aris@altlinux.org> пишет:
> 
> > > Некоторое время назад я сделал ошибку при git rebase и потерял
> > > значение
> > > по умолчанию для sysctl kernel.userns_restrict
> > > 
> > > Когда мне об этом сообщили, воспринял это как серьёзную проблему
> > > в
> > > безопасности и побежал исправлять.  
> > 
> > В каком un-def это было "исправлено"? 
> 
> в 5.14.18-alt1
> 
> 

Мне пришлось остаться на 5.14.17 поскольку и chrome, и firefox на
"пофиксенном" 21-ом стали съедать все ресурсы моего AMD A10 при
просмотре видео. От чего бы это? Может у всех процессоры помощнее?

-- 
Yuri N. Sedunov

Re: [devel] kernel.userns_restrict

[Anton V. Boyarshinov]

В Fri, 26 Nov 2021 11:30:23 +0300
Sergey V Turchin <zerg@altlinux.org> пишет:

> > Vladimir Didenko <vladimir.didenko@gmail.com> пишет:  
> > >  Может, авторы
> > > 
> > > изменений хотя бы страничку на нашей Вики оформят?  
> > 
> > https://www.altlinux.org/Userns_restrict  
> Там написано, что значение и 0 и 1 -- "глобально вЫключить ограничение".

Недоредактировал кусок c-n-p, спасибо!

Re: [devel] kernel.userns_restrict

[Anton V. Boyarshinov]

> > > В каком un-def это было "исправлено"?   
> > 
> > в 5.14.18-alt1
> > 
> >   
> 
> Мне пришлось остаться на 5.14.17 поскольку и chrome, и firefox на
> "пофиксенном" 21-ом стали съедать все ресурсы моего AMD A10 при
> просмотре видео. От чего бы это? Может у всех процессоры помощнее?

А если переключить kernel.userns_restrict в 0, проблема продолжает
воспроизводиться? 

Re: [devel] kernel.userns_restrict

[Anton Farygin]

On 26.11.2021 13:40, Anton V. Boyarshinov wrote:
>>>> В каком un-def это было "исправлено"?
>>> в 5.14.18-alt1
>>>
>>>    
>> Мне пришлось остаться на 5.14.17 поскольку и chrome, и firefox на
>> "пофиксенном" 21-ом стали съедать все ресурсы моего AMD A10 при
>> просмотре видео. От чего бы это? Может у всех процессоры помощнее?
> А если переключить kernel.userns_restrict в 0, проблема продолжает
> воспроизводиться?
Для chromium вот тут есть некоторые подробности:

https://github.com/puppeteer/puppeteer/blob/main/docs/troubleshooting.md#setting-up-chrome-linux-sandbox

\

Re: [devel] kernel.userns_restrict

[Anton V. Boyarshinov]

В Fri, 26 Nov 2021 13:46:46 +0300
Anton Farygin <rider@basealt.ru> пишет:

> On 26.11.2021 13:40, Anton V. Boyarshinov wrote:
> >>>> В каком un-def это было "исправлено"?  
> >>> в 5.14.18-alt1
> >>>
> >>>      
> >> Мне пришлось остаться на 5.14.17 поскольку и chrome, и firefox на
> >> "пофиксенном" 21-ом стали съедать все ресурсы моего AMD A10 при
> >> просмотре видео. От чего бы это? Может у всех процессоры помощнее?  
> > А если переключить kernel.userns_restrict в 0, проблема продолжает
> > воспроизводиться?  
> Для chromium вот тут есть некоторые подробности:
> 
> https://github.com/puppeteer/puppeteer/blob/main/docs/troubleshooting.md#setting-up-chrome-linux-sandbox

ls -l /usr/lib64/chromium/chrome-sandbox
-rws--x--x 1 root root 15968 июл 17 14:40 /usr/lib64/chromium/chrome-sandbox

Re: [devel] kernel.userns_restrict

[Anton Farygin]

On 26.11.2021 13:53, Anton V. Boyarshinov wrote:
> В Fri, 26 Nov 2021 13:46:46 +0300
> Anton Farygin <rider@basealt.ru> пишет:
>
>> On 26.11.2021 13:40, Anton V. Boyarshinov wrote:
>>>>>> В каком un-def это было "исправлено"?
>>>>> в 5.14.18-alt1
>>>>>
>>>>>       
>>>> Мне пришлось остаться на 5.14.17 поскольку и chrome, и firefox на
>>>> "пофиксенном" 21-ом стали съедать все ресурсы моего AMD A10 при
>>>> просмотре видео. От чего бы это? Может у всех процессоры помощнее?
>>> А если переключить kernel.userns_restrict в 0, проблема продолжает
>>> воспроизводиться?
>> Для chromium вот тут есть некоторые подробности:
>>
>> https://github.com/puppeteer/puppeteer/blob/main/docs/troubleshooting.md#setting-up-chrome-linux-sandbox
> ls -l /usr/lib64/chromium/chrome-sandbox
> -rws--x--x 1 root root 15968 июл 17 14:40 /usr/lib64/chromium/chrome-sandbox

Может ли так быть, что SUID'а недостаточно ? Надо всё отлаживать. К тому 
же у нас, например, execvp работает не так, как у всех для приложений, 
имеющих SUID. Может быть ещё что-то ограничено по сравнению с другими 
дистрибутивами.

Re: [devel] kernel.userns_restrict

[Sergey V Turchin]

On Friday, 26 November 2021 13:46:46 MSK Anton Farygin wrote:

[...]
> > А если переключить kernel.userns_restrict в 0, проблема продолжает
> > воспроизводиться?
> 
> Для chromium вот тут есть некоторые подробности:
> 
> https://github.com/puppeteer/puppeteer/blob/main/docs/troubleshooting.md#set
> ting-up-chrome-linux-sandbox
"[recommended] Enable user namespace cloning:"

# sysctl kernel.unprivileged_userns_clone
sysctl: cannot stat /proc/sys/kernel/unprivileged_userns_clone: Нет такого 
файла или каталога

# uname -r
5.10.80-std-def-alt1
недостаточно новое?

-- 
Regards, Sergey.

Re: [devel] kernel.userns_restrict

[Anton V. Boyarshinov]

В Fri, 26 Nov 2021 13:57:50 +0300
Anton Farygin <rider@basealt.ru> пишет:

> On 26.11.2021 13:53, Anton V. Boyarshinov wrote:
> > В Fri, 26 Nov 2021 13:46:46 +0300
> > Anton Farygin <rider@basealt.ru> пишет:
> >  
> >> On 26.11.2021 13:40, Anton V. Boyarshinov wrote:  
> >>>>>> В каком un-def это было "исправлено"?  
> >>>>> в 5.14.18-alt1
> >>>>>
> >>>>>         
> >>>> Мне пришлось остаться на 5.14.17 поскольку и chrome, и firefox на
> >>>> "пофиксенном" 21-ом стали съедать все ресурсы моего AMD A10 при
> >>>> просмотре видео. От чего бы это? Может у всех процессоры помощнее?  
> >>> А если переключить kernel.userns_restrict в 0, проблема продолжает
> >>> воспроизводиться?  
> >> Для chromium вот тут есть некоторые подробности:
> >>
> >> https://github.com/puppeteer/puppeteer/blob/main/docs/troubleshooting.md#setting-up-chrome-linux-sandbox  
> > ls -l /usr/lib64/chromium/chrome-sandbox
> > -rws--x--x 1 root root 15968 июл 17 14:40 /usr/lib64/chromium/chrome-sandbox  
> 
> Может ли так быть, что SUID'а недостаточно ? Надо всё отлаживать. К тому 
> же у нас, например, execvp работает не так, как у всех для приложений, 
> имеющих SUID. Может быть ещё что-то ограничено по сравнению с другими 
> дистрибутивами.

У меня в дистрибутивном chromium разницы в загрузке процессора при
просмотре видео в разных положениях userns_restrict не наблюдается.
Возможно, в данном случае дело в чём-то другом.
Хотя, конечно, может оказаться, что процессор мощноват или видео не то.

Re: [devel] kernel.userns_restrict

[Anton Farygin]

On 26.11.2021 14:11, Sergey V Turchin wrote:
> On Friday, 26 November 2021 13:46:46 MSK Anton Farygin wrote:
>
> [...]
>>> А если переключить kernel.userns_restrict в 0, проблема продолжает
>>> воспроизводиться?
>> Для chromium вот тут есть некоторые подробности:
>>
>> https://github.com/puppeteer/puppeteer/blob/main/docs/troubleshooting.md#set
>> ting-up-chrome-linux-sandbox
> "[recommended] Enable user namespace cloning:"
>
> # sysctl kernel.unprivileged_userns_clone
> sysctl: cannot stat /proc/sys/kernel/unprivileged_userns_clone: Нет такого
> файла или каталога
>
> # uname -r
> 5.10.80-std-def-alt1
> недостаточно новое?
>
Потому что именно эта ручка добавляется отдельным патчем.

Re: [devel] kernel.userns_restrict

[Anton V. Boyarshinov]

> > Для chromium вот тут есть некоторые подробности:
> > 
> > https://github.com/puppeteer/puppeteer/blob/main/docs/troubleshooting.md#set
> > ting-up-chrome-linux-sandbox  
> "[recommended] Enable user namespace cloning:"
> 
> # sysctl kernel.unprivileged_userns_clone
> sysctl: cannot stat /proc/sys/kernel/unprivileged_userns_clone: Нет такого 
> файла или каталога
> 
> # uname -r
> 5.10.80-std-def-alt1
> недостаточно новое?

У нас используется не такая реализация этого ограничения, как в Debian.
Имя параметра и смысл его значений другие. У нас как в Ubuntu. 

Re: [devel] kernel.userns_restrict

[Sergey V Turchin]

On Friday, 26 November 2021 14:17:26 MSK Anton V wrote:
> > > Для chromium вот тут есть некоторые подробности:
> > > 
> > > https://github.com/puppeteer/puppeteer/blob/main/docs/troubleshooting.md
> > > #set ting-up-chrome-linux-sandbox
> > 
> > "[recommended] Enable user namespace cloning:"
> > 
> > # sysctl kernel.unprivileged_userns_clone
> > sysctl: cannot stat /proc/sys/kernel/unprivileged_userns_clone: Нет такого
> > файла или каталога
> > 
> > # uname -r
> > 5.10.80-std-def-alt1
> > недостаточно новое?
> 
> У нас используется не такая реализация этого ограничения, как в Debian.
> Имя параметра и смысл его значений другие. У нас как в Ubuntu.
А где смысл значения "включено" лучше?

-- 
Regards, Sergey.

Re: [devel] kernel.userns_restrict

[Anton V. Boyarshinov]

В Fri, 26 Nov 2021 14:23:35 +0300
Sergey V Turchin <zerg@altlinux.org> пишет:

> > > # sysctl kernel.unprivileged_userns_clone
> > > sysctl: cannot stat /proc/sys/kernel/unprivileged_userns_clone: Нет такого
> > > файла или каталога
> > > 
> > > # uname -r
> > > 5.10.80-std-def-alt1
> > > недостаточно новое?  
> > 
> > У нас используется не такая реализация этого ограничения, как в Debian.
> > Имя параметра и смысл его значений другие. У нас как в Ubuntu.  
> А где смысл значения "включено" лучше?

unprivileged_userns_clone запрещены unpriv userns если 0
userns_restrict запрещены unpriv userns если 1

По поводу того какой патч и интерфейс лучше есть разные мнения, равно
как и по поводу того, какое положение правильное и нужно ли вообще
такое ограничение.

Глеб сделал "гибридный" патч, поддерживающий оба интерфейса, но смысл в
нём сомнителен, к тому же если один sysctl будет заодно переключать
другой, причём в другую сторону -- путаницы, боюсь, станет только
больше..

Re: [devel] kernel.userns_restrict

[Arseny Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]

On Fri, Nov 26, 2021 at 02:17:26PM +0300, Anton V. Boyarshinov wrote:
> > > Для chromium вот тут есть некоторые подробности:
> > > 
> > > https://github.com/puppeteer/puppeteer/blob/main/docs/troubleshooting.md#set
> > > ting-up-chrome-linux-sandbox  
> > "[recommended] Enable user namespace cloning:"
> > 
> > # sysctl kernel.unprivileged_userns_clone
> > sysctl: cannot stat /proc/sys/kernel/unprivileged_userns_clone: Нет такого 
> > файла или каталога
> > 
> > # uname -r
> > 5.10.80-std-def-alt1
> > недостаточно новое?
> 
> У нас используется не такая реализация этого ограничения, как в Debian.
> Имя параметра и смысл его значений другие.

Само по себе это не хорошо и не плохо...

> У нас как в Ubuntu. 

Нет, у нас не как в Ubuntu.
Спешу разочаровать:
  root@www-f7e3ae:~# grep D /etc/os-release
  ID=ubuntu
  ID_LIKE=debian
  VERSION_ID="18.04"
  VERSION_CODENAME=bionic
  UBUNTU_CODENAME=bionic
  root@www-f7e3ae:~# sysctl kernel.unprivileged_userns_clone
  kernel.unprivileged_userns_clone = 0
  root@www-f7e3ae:~# sysctl kernel.userns_restrict
  sysctl: cannot stat /proc/sys/kernel/userns_restrict: No such file or directory

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] kernel.userns_restrict

[Anton V. Boyarshinov]

В Fri, 26 Nov 2021 14:29:26 +0300
Arseny Maslennikov <arseny@altlinux.org> пишет:

> > У нас как в Ubuntu.   
> 
> Нет, у нас не как в Ubuntu.

Хмм... Занятно. Про "как в Ubuntu" я с чужих слов написал, пойду на
wiki исправлю...

> Спешу разочаровать:
>   root@www-f7e3ae:~# grep D /etc/os-release
>   ID=ubuntu
>   ID_LIKE=debian
>   VERSION_ID="18.04"
>   VERSION_CODENAME=bionic
>   UBUNTU_CODENAME=bionic
>   root@www-f7e3ae:~# sysctl kernel.unprivileged_userns_clone
>   kernel.unprivileged_userns_clone = 0
>   root@www-f7e3ae:~# sysctl kernel.userns_restrict
>   sysctl: cannot stat /proc/sys/kernel/userns_restrict: No such file or directory

Re: [devel] kernel.userns_restrict

[Sergey V Turchin]

On Friday, 26 November 2021 14:28:24 MSK Anton V wrote:
> В Fri, 26 Nov 2021 14:23:35 +0300
> 
> Sergey V Turchin <zerg@altlinux.org> пишет:
> > > > # sysctl kernel.unprivileged_userns_clone
> > > > sysctl: cannot stat /proc/sys/kernel/unprivileged_userns_clone: Нет
> > > > такого
> > > > файла или каталога
> > > > 
> > > > # uname -r
> > > > 5.10.80-std-def-alt1
> > > > недостаточно новое?
> > > 
> > > У нас используется не такая реализация этого ограничения, как в Debian.
> > > Имя параметра и смысл его значений другие. У нас как в Ubuntu.
> > 
> > А где смысл значения "включено" лучше?
> 
> unprivileged_userns_clone запрещены unpriv userns если 0
> userns_restrict запрещены unpriv userns если 1
> 
> По поводу того какой патч и интерфейс лучше есть разные мнения, равно
> как и по поводу того, какое положение правильное и нужно ли вообще
> такое ограничение.
Т.е. это абсолютно одно и то же, просто обёртка разная?

[...]

-- 
Regards, Sergey.

Re: [devel] kernel.userns_restrict

[Anton Farygin]

On 26.11.2021 14:35, Sergey V Turchin wrote:
> On Friday, 26 November 2021 14:28:24 MSK Anton V wrote:
>> В Fri, 26 Nov 2021 14:23:35 +0300
>>
>> Sergey V Turchin <zerg@altlinux.org> пишет:
>>>>> # sysctl kernel.unprivileged_userns_clone
>>>>> sysctl: cannot stat /proc/sys/kernel/unprivileged_userns_clone: Нет
>>>>> такого
>>>>> файла или каталога
>>>>>
>>>>> # uname -r
>>>>> 5.10.80-std-def-alt1
>>>>> недостаточно новое?
>>>> У нас используется не такая реализация этого ограничения, как в Debian.
>>>> Имя параметра и смысл его значений другие. У нас как в Ubuntu.
>>> А где смысл значения "включено" лучше?
>> unprivileged_userns_clone запрещены unpriv userns если 0
>> userns_restrict запрещены unpriv userns если 1
>>
>> По поводу того какой патч и интерфейс лучше есть разные мнения, равно
>> как и по поводу того, какое положение правильное и нужно ли вообще
>> такое ограничение.
> Т.е. это абсолютно одно и то же, просто обёртка разная?
>
Да, смысл одинаковый, но называется и параметры принимает по разной логике.

Re: [devel] kernel.userns_restrict

[Anton V. Boyarshinov]

В Fri, 26 Nov 2021 14:35:01 +0300
Sergey V Turchin <zerg@altlinux.org> пишет:

> > По поводу того какой патч и интерфейс лучше есть разные мнения, равно
> > как и по поводу того, какое положение правильное и нужно ли вообще
> > такое ограничение.  
> Т.е. это абсолютно одно и то же, просто обёртка разная?

Смысл один и тот же, но реализации разные (то есть внутри отличия не
только в имени sysctl).

Re: [devel] kernel.userns_restrict

[Sergey V Turchin]

On Friday, 26 November 2021 14:33:50 MSK Anton V wrote:
> В Fri, 26 Nov 2021 14:29:26 +0300
> 
> Arseny Maslennikov <arseny@altlinux.org> пишет:
> > > У нас как в Ubuntu.
> > 
> > Нет, у нас не как в Ubuntu.
> 
> Хмм... Занятно. Про "как в Ubuntu" я с чужих слов написал, пойду на
> wiki исправлю...
Может, лучше в сначала ядре исправить?

google:"kernel.userns_restrict" -- Результатов: примерно 90
google:"kernel.unprivileged_userns_clone" -- Результатов: примерно 6200
Похоже, что у нас опять "не как у всех".

[...]

-- 
Regards, Sergey.

Re: [devel] kernel.userns_restrict

[Anton V. Boyarshinov]

В Fri, 26 Nov 2021 14:45:51 +0300
Sergey V Turchin <zerg@altlinux.org> пишет:

> On Friday, 26 November 2021 14:33:50 MSK Anton V wrote:
> > В Fri, 26 Nov 2021 14:29:26 +0300
> > 
> > Arseny Maslennikov <arseny@altlinux.org> пишет:  
> > > > У нас как в Ubuntu.  
> > > 
> > > Нет, у нас не как в Ubuntu.  
> > 
> > Хмм... Занятно. Про "как в Ubuntu" я с чужих слов написал, пойду на
> > wiki исправлю...  
> Может, лучше в сначала ядре исправить?

В ядре менять это надо подумать, посоветоваться и проверить, а на wiki
можно прямо сейчас привести в соответствие с реальностью..

> 
> google:"kernel.userns_restrict" -- Результатов: примерно 90
> google:"kernel.unprivileged_userns_clone" -- Результатов: примерно 6200
> Похоже, что у нас опять "не как у всех".
> 
> [...]
> 

Re: [devel] kernel.userns_restrict

[Yuri Sedunov]

В Пт, 26/11/2021 в 14:15 +0300, Anton V. Boyarshinov пишет:
> В Fri, 26 Nov 2021 13:57:50 +0300
> Anton Farygin <rider@basealt.ru> пишет:
> 
> > On 26.11.2021 13:53, Anton V. Boyarshinov wrote:
> > > В Fri, 26 Nov 2021 13:46:46 +0300
> > > Anton Farygin <rider@basealt.ru> пишет:
> > >  
> > > > On 26.11.2021 13:40, Anton V. Boyarshinov wrote:  
> > > > > > > > В каком un-def это было "исправлено"?  
> > > > > > > в 5.14.18-alt1
> > > > > > > 
> > > > > > >         
> > > > > > Мне пришлось остаться на 5.14.17 поскольку и chrome, и
> > > > > > firefox на
> > > > > > "пофиксенном" 21-ом стали съедать все ресурсы моего AMD A10
> > > > > > при
> > > > > > просмотре видео. От чего бы это? Может у всех процессоры
> > > > > > помощнее?  
> > > > > А если переключить kernel.userns_restrict в 0, проблема
> > > > > продолжает
> > > > > воспроизводиться?  
> > > > Для chromium вот тут есть некоторые подробности:
> > > > 
> > > > https://github.com/puppeteer/puppeteer/blob/main/docs/troubleshooting.md#setting-up-chrome-linux-sandbox
> > > >  
> > > ls -l /usr/lib64/chromium/chrome-sandbox
> > > -rws--x--x 1 root root 15968 июл 17 14:40
> > > /usr/lib64/chromium/chrome-sandbox  
> > 
> > Может ли так быть, что SUID'а недостаточно ? Надо всё отлаживать. К
> > тому 
> > же у нас, например, execvp работает не так, как у всех для
> > приложений, 
> > имеющих SUID. Может быть ещё что-то ограничено по сравнению с
> > другими 
> > дистрибутивами.
> 
> У меня в дистрибутивном chromium разницы в загрузке процессора при
> просмотре видео в разных положениях userns_restrict не наблюдается.
> Возможно, в данном случае дело в чём-то другом.
> Хотя, конечно, может оказаться, что процессор мощноват или видео не
> то.

Ну, вот разница есть. Стер пыль с HP ENVY 360 на Ryzen 2500U, который,
кстати, успел устареть, пока его поддержка появилась в нашем ядре, в
отличие от такового имени забаненного lakostis@. 
Chromium youtube Россия 24
На ядре 5.14.9 ~ 18% userns_restrict=0
--"--   5.4.21 ~ 35% userns_restrict=1
На AMD A10, напомню, около 100%, заикается на 21-ом ядре.





-- 
Yuri N. Sedunov

Re: [devel] kernel.userns_restrict

[Dmitry V. Levin]

On Fri, Nov 26, 2021 at 03:46:46PM +0300, Yuri Sedunov wrote:
[...]
> На ядре 5.14.9 ~ 18% userns_restrict=0
> --"--   5.4.21 ~ 35% userns_restrict=1

Просьба всё-таки сравнивать разные состояния userns_restrict
на одном и том же ядре.


-- 
ldv

Re: [devel] kernel.userns_restrict

[Yuri Sedunov]

В Пт, 26/11/2021 в 15:50 +0300, Dmitry V. Levin пишет:
> On Fri, Nov 26, 2021 at 03:46:46PM +0300, Yuri Sedunov wrote:
> [...]
> > На ядре 5.14.9 ~ 18% userns_restrict=0
> > --"--   5.4.21 ~ 35% userns_restrict=1
> 
> Просьба всё-таки сравнивать разные состояния userns_restrict
> на одном и том же ядре.
> 
Таки, информации более чем достаточно.


-- 
Yuri N. Sedunov