* [devel] kernel.userns_restrict @ 2021-11-18 11:36 Anton V. Boyarshinov 2021-11-18 11:37 ` Anton V. Boyarshinov ` (4 more replies) 0 siblings, 5 replies; 56+ messages in thread From: Anton V. Boyarshinov @ 2021-11-18 11:36 UTC (permalink / raw) To: ALT Linux Team development discussions Добрый день Некоторое время назад я сделал ошибку при 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 и я считаю, что это блокер. Но на что вешать непонятно, ни к пуговицам, ни к рукавам претензий нет, но пиджак в целом никуда не годен. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-18 11:36 [devel] kernel.userns_restrict Anton V. Boyarshinov @ 2021-11-18 11:37 ` Anton V. Boyarshinov 2021-11-18 12:32 ` Anton Farygin 2021-11-18 11:43 ` Dmitry V. Levin ` (3 subsequent siblings) 4 siblings, 1 reply; 56+ messages in thread From: Anton V. Boyarshinov @ 2021-11-18 11:37 UTC (permalink / raw) To: devel > > Но некоторое время спустя, мне открылась бездна: Тут оказалось недокопировано: [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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-18 11:37 ` Anton V. Boyarshinov @ 2021-11-18 12:32 ` Anton Farygin 0 siblings, 0 replies; 56+ messages in thread From: Anton Farygin @ 2021-11-18 12:32 UTC (permalink / raw) To: devel 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 такое поведение ядра. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-18 11:36 [devel] kernel.userns_restrict Anton V. Boyarshinov 2021-11-18 11:37 ` Anton V. Boyarshinov @ 2021-11-18 11:43 ` Dmitry V. Levin 2021-11-18 12:01 ` Dmitry V. Levin 2021-11-18 12:06 ` Mikhail Efremov 2021-11-19 13:41 ` Alexey Sheplyakov ` (2 subsequent siblings) 4 siblings, 2 replies; 56+ messages in thread From: Dmitry V. Levin @ 2021-11-18 11:43 UTC (permalink / raw) To: devel 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-18 11:43 ` Dmitry V. Levin @ 2021-11-18 12:01 ` Dmitry V. Levin 2021-11-19 15:25 ` Anton V. Boyarshinov 2021-11-18 12:06 ` Mikhail Efremov 1 sibling, 1 reply; 56+ messages in thread From: Dmitry V. Levin @ 2021-11-18 12:01 UTC (permalink / raw) To: devel 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-18 12:01 ` Dmitry V. Levin @ 2021-11-19 15:25 ` Anton V. Boyarshinov 0 siblings, 0 replies; 56+ messages in thread From: Anton V. Boyarshinov @ 2021-11-19 15:25 UTC (permalink / raw) To: Dmitry V. Levin; +Cc: ALT Linux Team development discussions В 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/ ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-18 11:43 ` Dmitry V. Levin 2021-11-18 12:01 ` Dmitry V. Levin @ 2021-11-18 12:06 ` Mikhail Efremov 2021-11-18 12:12 ` Dmitry V. Levin 1 sibling, 1 reply; 56+ messages in thread From: Mikhail Efremov @ 2021-11-18 12:06 UTC (permalink / raw) To: ALT Linux Team development discussions 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-18 12:06 ` Mikhail Efremov @ 2021-11-18 12:12 ` Dmitry V. Levin 2021-11-18 12:15 ` Anton Farygin 0 siblings, 1 reply; 56+ messages in thread From: Dmitry V. Levin @ 2021-11-18 12:12 UTC (permalink / raw) To: ALT Linux Team development discussions 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-18 12:12 ` Dmitry V. Levin @ 2021-11-18 12:15 ` Anton Farygin 2021-11-18 12:18 ` Dmitry V. Levin 0 siblings, 1 reply; 56+ messages in thread From: Anton Farygin @ 2021-11-18 12:15 UTC (permalink / raw) To: devel 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 должен остаться рабочим в установленной системе. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-18 12:15 ` Anton Farygin @ 2021-11-18 12:18 ` Dmitry V. Levin 2021-11-18 12:21 ` Anton Farygin 0 siblings, 1 reply; 56+ messages in thread From: Dmitry V. Levin @ 2021-11-18 12:18 UTC (permalink / raw) To: devel 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-18 12:18 ` Dmitry V. Levin @ 2021-11-18 12:21 ` Anton Farygin 2021-11-18 12:32 ` Vladimir D. Seleznev 2021-11-18 12:34 ` Dmitry V. Levin 0 siblings, 2 replies; 56+ messages in thread From: Anton Farygin @ 2021-11-18 12:21 UTC (permalink / raw) To: devel On 18.11.2021 15:18, Dmitry V. Levin wrote: >> Делайте что хотите, но в результате bubblewrap должен остаться рабочим в >> установленной системе. > Я считаю безопасность ОС важнее, чем работоспособность bubblewrap. > Если компромисса не найдётся, я без колебаний пожертвую bubblewrap'ом. если компромисса не найдётся я без колебаний перейду на другой дистрибутив. Потому что без bubblerwap у нас будет сломан целый слой, его использующий. Лично мне важен работоспособный flatpack и opam. А чем так плохи userns и за что мы боремся, можно рассказать ? ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-18 12:21 ` Anton Farygin @ 2021-11-18 12:32 ` Vladimir D. Seleznev 2021-11-18 12:41 ` Arseny Maslennikov 2021-11-18 12:34 ` Dmitry V. Levin 1 sibling, 1 reply; 56+ messages in thread From: Vladimir D. Seleznev @ 2021-11-18 12:32 UTC (permalink / raw) To: ALT Linux Team development discussions 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-18 12:32 ` Vladimir D. Seleznev @ 2021-11-18 12:41 ` Arseny Maslennikov 2021-11-18 12:50 ` Dmitry V. Levin 0 siblings, 1 reply; 56+ messages in thread From: Arseny Maslennikov @ 2021-11-18 12:41 UTC (permalink / raw) To: ALT Linux Team development discussions [-- 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 --] ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-18 12:41 ` Arseny Maslennikov @ 2021-11-18 12:50 ` Dmitry V. Levin 0 siblings, 0 replies; 56+ messages in thread From: Dmitry V. Levin @ 2021-11-18 12:50 UTC (permalink / raw) To: devel 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-18 12:21 ` Anton Farygin 2021-11-18 12:32 ` Vladimir D. Seleznev @ 2021-11-18 12:34 ` Dmitry V. Levin 2021-11-18 12:40 ` Anton Farygin 1 sibling, 1 reply; 56+ messages in thread From: Dmitry V. Levin @ 2021-11-18 12:34 UTC (permalink / raw) To: devel 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-18 12:34 ` Dmitry V. Levin @ 2021-11-18 12:40 ` Anton Farygin 2021-11-18 12:44 ` Dmitry V. Levin 0 siblings, 1 reply; 56+ messages in thread From: Anton Farygin @ 2021-11-18 12:40 UTC (permalink / raw) To: devel 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 ) с этим разобрался - может ли и если да, то какой ценой. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-18 12:40 ` Anton Farygin @ 2021-11-18 12:44 ` Dmitry V. Levin 2021-11-18 12:47 ` Anton Farygin 0 siblings, 1 reply; 56+ messages in thread From: Dmitry V. Levin @ 2021-11-18 12:44 UTC (permalink / raw) To: devel 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-18 12:44 ` Dmitry V. Levin @ 2021-11-18 12:47 ` Anton Farygin 2021-11-18 12:55 ` Anton Farygin 2021-11-20 18:21 ` mikhailnov 0 siblings, 2 replies; 56+ messages in thread From: Anton Farygin @ 2021-11-18 12:47 UTC (permalink / raw) To: devel 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 >> ) с этим разобрался - может ли и если да, то какой ценой. > Наверное, что-нибудь перестанет работать. Было бы неплохо, если бы кто-то разобрался. У меня сейчас на это времени совсем нет, к сожалению. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-18 12:47 ` Anton Farygin @ 2021-11-18 12:55 ` Anton Farygin 2021-11-20 18:21 ` mikhailnov 1 sibling, 0 replies; 56+ messages in thread From: Anton Farygin @ 2021-11-18 12:55 UTC (permalink / raw) To: devel On 18.11.2021 15:47, Anton Farygin wrote: >> Так проблема именно в том, что bubblewrap вытягивается по >> зависимостям почти >> у всех, хотя используется далеко не всеми. > Так может быть решать именно эту проблему ? Я к тому, что opam, например, не зависит. Просто не работает ;) ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-18 12:47 ` Anton Farygin 2021-11-18 12:55 ` Anton Farygin @ 2021-11-20 18:21 ` mikhailnov 1 sibling, 0 replies; 56+ messages in thread From: mikhailnov @ 2021-11-20 18:21 UTC (permalink / raw) To: devel 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. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-18 11:36 [devel] kernel.userns_restrict Anton V. Boyarshinov 2021-11-18 11:37 ` Anton V. Boyarshinov 2021-11-18 11:43 ` Dmitry V. Levin @ 2021-11-19 13:41 ` Alexey Sheplyakov 2021-11-19 14:10 ` Vladimir D. Seleznev 2021-11-24 15:52 ` Vladimir Didenko 2021-11-26 7:29 ` Yuri Sedunov 4 siblings, 1 reply; 56+ messages in thread From: Alexey Sheplyakov @ 2021-11-19 13:41 UTC (permalink / raw) To: devel Здравствуйте! On 18.11.2021 15:36, Anton V. Boyarshinov wrote: > Добрый день > > Некоторое время назад я сделал ошибку при git rebase и потерял значение > по умолчанию для sysctl kernel.userns_restrict > > Когда мне об этом сообщили, воспринял это как серьёзную проблему в > безопасности и побежал исправлять. С той же степенью обоснованности "серьёзной проблемой" является наличие сетевых интерфейсов. И отключить их по умолчанию для пущей безопасности. А можно и вообще компьютер не включать. Так 100% ни один злодей не пройдёт. > Таким образом, нам в любой десктопный дистрибутив с gtk3 нечувствительно приезжает kernel.userns_restrict=0 И очень хорошо, что хоть каким-то дистрибутивом можно прямо из коробки пользоваться. А не чинить сломанное излишне тревожными гражданами. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-19 13:41 ` Alexey Sheplyakov @ 2021-11-19 14:10 ` Vladimir D. Seleznev 0 siblings, 0 replies; 56+ messages in thread From: Vladimir D. Seleznev @ 2021-11-19 14:10 UTC (permalink / raw) To: ALT Linux Team development discussions 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-18 11:36 [devel] kernel.userns_restrict Anton V. Boyarshinov ` (2 preceding siblings ...) 2021-11-19 13:41 ` Alexey Sheplyakov @ 2021-11-24 15:52 ` Vladimir Didenko 2021-11-24 16:03 ` Vladimir D. Seleznev ` (2 more replies) 2021-11-26 7:29 ` Yuri Sedunov 4 siblings, 3 replies; 56+ messages in thread From: Vladimir Didenko @ 2021-11-24 15:52 UTC (permalink / raw) To: ALT Linux Team development discussions чт, 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. Можно посмотреть на количество дупликатов, чтобы понять, что у пользователей отвалится куча приложений. -- С уважением, Владимир. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-24 15:52 ` Vladimir Didenko @ 2021-11-24 16:03 ` Vladimir D. Seleznev 2021-11-24 16:08 ` Vladimir Didenko 2021-11-24 19:59 ` Aleksey Novodvorsky 2021-11-25 7:43 ` Anton V. Boyarshinov 2021-11-26 7:55 ` Anton V. Boyarshinov 2 siblings, 2 replies; 56+ messages in thread From: Vladimir D. Seleznev @ 2021-11-24 16:03 UTC (permalink / raw) To: ALT Linux Team development discussions 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-24 16:03 ` Vladimir D. Seleznev @ 2021-11-24 16:08 ` Vladimir Didenko 2021-11-24 16:18 ` Vladimir D. Seleznev 2021-11-26 7:25 ` Anton V. Boyarshinov 2021-11-24 19:59 ` Aleksey Novodvorsky 1 sibling, 2 replies; 56+ messages in thread From: Vladimir Didenko @ 2021-11-24 16:08 UTC (permalink / raw) To: ALT Linux Team development discussions ср, 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. Это тоже безопаснее для пользователя? -- С уважением, Владимир. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-24 16:08 ` Vladimir Didenko @ 2021-11-24 16:18 ` Vladimir D. Seleznev 2021-11-26 7:25 ` Anton V. Boyarshinov 1 sibling, 0 replies; 56+ messages in thread From: Vladimir D. Seleznev @ 2021-11-24 16:18 UTC (permalink / raw) To: ALT Linux Team development discussions 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-24 16:08 ` Vladimir Didenko 2021-11-24 16:18 ` Vladimir D. Seleznev @ 2021-11-26 7:25 ` Anton V. Boyarshinov 1 sibling, 0 replies; 56+ messages in thread From: Anton V. Boyarshinov @ 2021-11-26 7:25 UTC (permalink / raw) To: Vladimir Didenko; +Cc: ALT Linux Team development discussions В 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... ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-24 16:03 ` Vladimir D. Seleznev 2021-11-24 16:08 ` Vladimir Didenko @ 2021-11-24 19:59 ` Aleksey Novodvorsky 1 sibling, 0 replies; 56+ messages in thread From: Aleksey Novodvorsky @ 2021-11-24 19:59 UTC (permalink / raw) To: ALT Linux Team development discussions ср, 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-24 15:52 ` Vladimir Didenko 2021-11-24 16:03 ` Vladimir D. Seleznev @ 2021-11-25 7:43 ` Anton V. Boyarshinov 2021-11-26 7:55 ` Anton V. Boyarshinov 2 siblings, 0 replies; 56+ messages in thread From: Anton V. Boyarshinov @ 2021-11-25 7:43 UTC (permalink / raw) To: Vladimir Didenko; +Cc: ALT Linux Team development discussions В Wed, 24 Nov 2021 18:52:33 +0300 Vladimir Didenko <vladimir.didenko@gmail.com> пишет: > Хорошо, что я читаю devel, и понял, что причина это удаление конфига > из bubblewrap, но как быть обычному пользователю? Вообще говоря, если какие-то программы работали только благодаря наличию этого конфига в совершенно для них постороннем пакете, это было неправильно. И то, что мы теперь знаем об этом, вообще говоря благо. Что с этим благом делать -- другой вопрос. А я-то всё удивлялся, почему на выключение unpriv userns по умолчанию ни разу не поступало ни одной жалобы! Правда, удивлялся я недостаточно, чтоб изучить почему именно жалобы не поступают, а зря. > Может, авторы > изменений хотя бы страничку на нашей Вики оформят? А еще, мы точно > уверены, что дефолт, при котором программы без проблем работающие на > Ubuntu/Fedora/Arch у нас просто не запускаются это хороший дефолт? Видимо, всё-таки надо делать более/менее удобный переключатель в дополнение к возможности написать что-нибудь в /etc/sysctl.d ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-24 15:52 ` Vladimir Didenko 2021-11-24 16:03 ` Vladimir D. Seleznev 2021-11-25 7:43 ` Anton V. Boyarshinov @ 2021-11-26 7:55 ` Anton V. Boyarshinov 2021-11-26 8:30 ` Sergey V Turchin 2 siblings, 1 reply; 56+ messages in thread From: Anton V. Boyarshinov @ 2021-11-26 7:55 UTC (permalink / raw) To: Vladimir Didenko; +Cc: ALT Linux Team development discussions В 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 по дефолту, нет чтоб "как у всех"... ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-26 7:55 ` Anton V. Boyarshinov @ 2021-11-26 8:30 ` Sergey V Turchin 2021-11-26 8:49 ` Anton V. Boyarshinov 0 siblings, 1 reply; 56+ messages in thread From: Sergey V Turchin @ 2021-11-26 8:30 UTC (permalink / raw) To: ALT Linux Team development discussions 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. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-26 8:30 ` Sergey V Turchin @ 2021-11-26 8:49 ` Anton V. Boyarshinov 0 siblings, 0 replies; 56+ messages in thread From: Anton V. Boyarshinov @ 2021-11-26 8:49 UTC (permalink / raw) To: Sergey V Turchin; +Cc: ALT Linux Team development discussions В 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, спасибо! ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-18 11:36 [devel] kernel.userns_restrict Anton V. Boyarshinov ` (3 preceding siblings ...) 2021-11-24 15:52 ` Vladimir Didenko @ 2021-11-26 7:29 ` Yuri Sedunov 2021-11-26 8:33 ` Anton V. Boyarshinov 4 siblings, 1 reply; 56+ messages in thread From: Yuri Sedunov @ 2021-11-26 7:29 UTC (permalink / raw) To: devel В Чт, 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-26 7:29 ` Yuri Sedunov @ 2021-11-26 8:33 ` Anton V. Boyarshinov 2021-11-26 8:36 ` Anton Farygin 2021-11-26 8:48 ` Yuri Sedunov 0 siblings, 2 replies; 56+ messages in thread From: Anton V. Boyarshinov @ 2021-11-26 8:33 UTC (permalink / raw) To: Yuri Sedunov; +Cc: ALT Linux Team development discussions В 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 > ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-26 8:33 ` Anton V. Boyarshinov @ 2021-11-26 8:36 ` Anton Farygin 2021-11-26 8:48 ` Yuri Sedunov 1 sibling, 0 replies; 56+ messages in thread From: Anton Farygin @ 2021-11-26 8:36 UTC (permalink / raw) To: devel 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. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-26 8:33 ` Anton V. Boyarshinov 2021-11-26 8:36 ` Anton Farygin @ 2021-11-26 8:48 ` Yuri Sedunov 2021-11-26 10:40 ` Anton V. Boyarshinov 1 sibling, 1 reply; 56+ messages in thread From: Yuri Sedunov @ 2021-11-26 8:48 UTC (permalink / raw) To: devel В Пт, 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-26 8:48 ` Yuri Sedunov @ 2021-11-26 10:40 ` Anton V. Boyarshinov 2021-11-26 10:46 ` Anton Farygin 0 siblings, 1 reply; 56+ messages in thread From: Anton V. Boyarshinov @ 2021-11-26 10:40 UTC (permalink / raw) To: Yuri Sedunov; +Cc: ALT Linux Team development discussions > > > В каком un-def это было "исправлено"? > > > > в 5.14.18-alt1 > > > > > > Мне пришлось остаться на 5.14.17 поскольку и chrome, и firefox на > "пофиксенном" 21-ом стали съедать все ресурсы моего AMD A10 при > просмотре видео. От чего бы это? Может у всех процессоры помощнее? А если переключить kernel.userns_restrict в 0, проблема продолжает воспроизводиться? ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-26 10:40 ` Anton V. Boyarshinov @ 2021-11-26 10:46 ` Anton Farygin 2021-11-26 10:53 ` Anton V. Boyarshinov 2021-11-26 11:11 ` Sergey V Turchin 0 siblings, 2 replies; 56+ messages in thread From: Anton Farygin @ 2021-11-26 10:46 UTC (permalink / raw) To: devel 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 \ ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-26 10:46 ` Anton Farygin @ 2021-11-26 10:53 ` Anton V. Boyarshinov 2021-11-26 10:57 ` Anton Farygin 2021-11-26 11:11 ` Sergey V Turchin 1 sibling, 1 reply; 56+ messages in thread From: Anton V. Boyarshinov @ 2021-11-26 10:53 UTC (permalink / raw) To: Anton Farygin; +Cc: ALT Linux Team development discussions В 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-26 10:53 ` Anton V. Boyarshinov @ 2021-11-26 10:57 ` Anton Farygin 2021-11-26 11:15 ` Anton V. Boyarshinov 0 siblings, 1 reply; 56+ messages in thread From: Anton Farygin @ 2021-11-26 10:57 UTC (permalink / raw) To: devel 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. Может быть ещё что-то ограничено по сравнению с другими дистрибутивами. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-26 10:57 ` Anton Farygin @ 2021-11-26 11:15 ` Anton V. Boyarshinov 2021-11-26 12:46 ` Yuri Sedunov 0 siblings, 1 reply; 56+ messages in thread From: Anton V. Boyarshinov @ 2021-11-26 11:15 UTC (permalink / raw) To: Anton Farygin; +Cc: ALT Linux Team development discussions В 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 не наблюдается. Возможно, в данном случае дело в чём-то другом. Хотя, конечно, может оказаться, что процессор мощноват или видео не то. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-26 11:15 ` Anton V. Boyarshinov @ 2021-11-26 12:46 ` Yuri Sedunov 2021-11-26 12:50 ` Dmitry V. Levin 0 siblings, 1 reply; 56+ messages in thread From: Yuri Sedunov @ 2021-11-26 12:46 UTC (permalink / raw) To: devel В Пт, 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-26 12:46 ` Yuri Sedunov @ 2021-11-26 12:50 ` Dmitry V. Levin 2021-11-26 12:54 ` Yuri Sedunov 0 siblings, 1 reply; 56+ messages in thread From: Dmitry V. Levin @ 2021-11-26 12:50 UTC (permalink / raw) To: devel 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-26 12:50 ` Dmitry V. Levin @ 2021-11-26 12:54 ` Yuri Sedunov 0 siblings, 0 replies; 56+ messages in thread From: Yuri Sedunov @ 2021-11-26 12:54 UTC (permalink / raw) To: devel В Пт, 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-26 10:46 ` Anton Farygin 2021-11-26 10:53 ` Anton V. Boyarshinov @ 2021-11-26 11:11 ` Sergey V Turchin 2021-11-26 11:17 ` Anton Farygin 2021-11-26 11:17 ` Anton V. Boyarshinov 1 sibling, 2 replies; 56+ messages in thread From: Sergey V Turchin @ 2021-11-26 11:11 UTC (permalink / raw) To: ALT Linux Team development discussions 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. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-26 11:11 ` Sergey V Turchin @ 2021-11-26 11:17 ` Anton Farygin 2021-11-26 11:17 ` Anton V. Boyarshinov 1 sibling, 0 replies; 56+ messages in thread From: Anton Farygin @ 2021-11-26 11:17 UTC (permalink / raw) To: devel 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 > недостаточно новое? > Потому что именно эта ручка добавляется отдельным патчем. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-26 11:11 ` Sergey V Turchin 2021-11-26 11:17 ` Anton Farygin @ 2021-11-26 11:17 ` Anton V. Boyarshinov 2021-11-26 11:23 ` Sergey V Turchin 2021-11-26 11:29 ` Arseny Maslennikov 1 sibling, 2 replies; 56+ messages in thread From: Anton V. Boyarshinov @ 2021-11-26 11:17 UTC (permalink / raw) To: Sergey V Turchin; +Cc: ALT Linux Team development discussions > > Для 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. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-26 11:17 ` Anton V. Boyarshinov @ 2021-11-26 11:23 ` Sergey V Turchin 2021-11-26 11:28 ` Anton V. Boyarshinov 2021-11-26 11:29 ` Arseny Maslennikov 1 sibling, 1 reply; 56+ messages in thread From: Sergey V Turchin @ 2021-11-26 11:23 UTC (permalink / raw) To: ALT Linux Team development discussions 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. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-26 11:23 ` Sergey V Turchin @ 2021-11-26 11:28 ` Anton V. Boyarshinov 2021-11-26 11:35 ` Sergey V Turchin 0 siblings, 1 reply; 56+ messages in thread From: Anton V. Boyarshinov @ 2021-11-26 11:28 UTC (permalink / raw) To: Sergey V Turchin; +Cc: ALT Linux Team development discussions В 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 будет заодно переключать другой, причём в другую сторону -- путаницы, боюсь, станет только больше.. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-26 11:28 ` Anton V. Boyarshinov @ 2021-11-26 11:35 ` Sergey V Turchin 2021-11-26 11:36 ` Anton Farygin 2021-11-26 11:36 ` Anton V. Boyarshinov 0 siblings, 2 replies; 56+ messages in thread From: Sergey V Turchin @ 2021-11-26 11:35 UTC (permalink / raw) To: ALT Linux Team development discussions 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. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-26 11:35 ` Sergey V Turchin @ 2021-11-26 11:36 ` Anton Farygin 2021-11-26 11:36 ` Anton V. Boyarshinov 1 sibling, 0 replies; 56+ messages in thread From: Anton Farygin @ 2021-11-26 11:36 UTC (permalink / raw) To: devel 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 >> >> По поводу того какой патч и интерфейс лучше есть разные мнения, равно >> как и по поводу того, какое положение правильное и нужно ли вообще >> такое ограничение. > Т.е. это абсолютно одно и то же, просто обёртка разная? > Да, смысл одинаковый, но называется и параметры принимает по разной логике. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-26 11:35 ` Sergey V Turchin 2021-11-26 11:36 ` Anton Farygin @ 2021-11-26 11:36 ` Anton V. Boyarshinov 1 sibling, 0 replies; 56+ messages in thread From: Anton V. Boyarshinov @ 2021-11-26 11:36 UTC (permalink / raw) To: Sergey V Turchin; +Cc: ALT Linux Team development discussions В Fri, 26 Nov 2021 14:35:01 +0300 Sergey V Turchin <zerg@altlinux.org> пишет: > > По поводу того какой патч и интерфейс лучше есть разные мнения, равно > > как и по поводу того, какое положение правильное и нужно ли вообще > > такое ограничение. > Т.е. это абсолютно одно и то же, просто обёртка разная? Смысл один и тот же, но реализации разные (то есть внутри отличия не только в имени sysctl). ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-26 11:17 ` Anton V. Boyarshinov 2021-11-26 11:23 ` Sergey V Turchin @ 2021-11-26 11:29 ` Arseny Maslennikov 2021-11-26 11:33 ` Anton V. Boyarshinov 1 sibling, 1 reply; 56+ messages in thread From: Arseny Maslennikov @ 2021-11-26 11:29 UTC (permalink / raw) To: ALT Linux Team development discussions [-- 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 --] ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-26 11:29 ` Arseny Maslennikov @ 2021-11-26 11:33 ` Anton V. Boyarshinov 2021-11-26 11:45 ` Sergey V Turchin 0 siblings, 1 reply; 56+ messages in thread From: Anton V. Boyarshinov @ 2021-11-26 11:33 UTC (permalink / raw) To: Arseny Maslennikov; +Cc: ALT Linux Team development discussions В 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 ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-26 11:33 ` Anton V. Boyarshinov @ 2021-11-26 11:45 ` Sergey V Turchin 2021-11-26 12:12 ` Anton V. Boyarshinov 0 siblings, 1 reply; 56+ messages in thread From: Sergey V Turchin @ 2021-11-26 11:45 UTC (permalink / raw) To: ALT Linux Team development discussions 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. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [devel] kernel.userns_restrict 2021-11-26 11:45 ` Sergey V Turchin @ 2021-11-26 12:12 ` Anton V. Boyarshinov 0 siblings, 0 replies; 56+ messages in thread From: Anton V. Boyarshinov @ 2021-11-26 12:12 UTC (permalink / raw) To: Sergey V Turchin; +Cc: ALT Linux Team development discussions В 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 > Похоже, что у нас опять "не как у всех". > > [...] > ^ permalink raw reply [flat|nested] 56+ messages in thread
end of thread, other threads:[~2021-11-26 12:54 UTC | newest] Thread overview: 56+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-11-18 11:36 [devel] kernel.userns_restrict Anton V. Boyarshinov 2021-11-18 11:37 ` Anton V. Boyarshinov 2021-11-18 12:32 ` Anton Farygin 2021-11-18 11:43 ` Dmitry V. Levin 2021-11-18 12:01 ` Dmitry V. Levin 2021-11-19 15:25 ` Anton V. Boyarshinov 2021-11-18 12:06 ` Mikhail Efremov 2021-11-18 12:12 ` Dmitry V. Levin 2021-11-18 12:15 ` Anton Farygin 2021-11-18 12:18 ` Dmitry V. Levin 2021-11-18 12:21 ` Anton Farygin 2021-11-18 12:32 ` Vladimir D. Seleznev 2021-11-18 12:41 ` Arseny Maslennikov 2021-11-18 12:50 ` Dmitry V. Levin 2021-11-18 12:34 ` Dmitry V. Levin 2021-11-18 12:40 ` Anton Farygin 2021-11-18 12:44 ` Dmitry V. Levin 2021-11-18 12:47 ` Anton Farygin 2021-11-18 12:55 ` Anton Farygin 2021-11-20 18:21 ` mikhailnov 2021-11-19 13:41 ` Alexey Sheplyakov 2021-11-19 14:10 ` Vladimir D. Seleznev 2021-11-24 15:52 ` Vladimir Didenko 2021-11-24 16:03 ` Vladimir D. Seleznev 2021-11-24 16:08 ` Vladimir Didenko 2021-11-24 16:18 ` Vladimir D. Seleznev 2021-11-26 7:25 ` Anton V. Boyarshinov 2021-11-24 19:59 ` Aleksey Novodvorsky 2021-11-25 7:43 ` Anton V. Boyarshinov 2021-11-26 7:55 ` Anton V. Boyarshinov 2021-11-26 8:30 ` Sergey V Turchin 2021-11-26 8:49 ` Anton V. Boyarshinov 2021-11-26 7:29 ` Yuri Sedunov 2021-11-26 8:33 ` Anton V. Boyarshinov 2021-11-26 8:36 ` Anton Farygin 2021-11-26 8:48 ` Yuri Sedunov 2021-11-26 10:40 ` Anton V. Boyarshinov 2021-11-26 10:46 ` Anton Farygin 2021-11-26 10:53 ` Anton V. Boyarshinov 2021-11-26 10:57 ` Anton Farygin 2021-11-26 11:15 ` Anton V. Boyarshinov 2021-11-26 12:46 ` Yuri Sedunov 2021-11-26 12:50 ` Dmitry V. Levin 2021-11-26 12:54 ` Yuri Sedunov 2021-11-26 11:11 ` Sergey V Turchin 2021-11-26 11:17 ` Anton Farygin 2021-11-26 11:17 ` Anton V. Boyarshinov 2021-11-26 11:23 ` Sergey V Turchin 2021-11-26 11:28 ` Anton V. Boyarshinov 2021-11-26 11:35 ` Sergey V Turchin 2021-11-26 11:36 ` Anton Farygin 2021-11-26 11:36 ` Anton V. Boyarshinov 2021-11-26 11:29 ` Arseny Maslennikov 2021-11-26 11:33 ` Anton V. Boyarshinov 2021-11-26 11:45 ` Sergey V Turchin 2021-11-26 12:12 ` Anton V. Boyarshinov
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git