You are not logged in.
Unless I'm missing something, it appears Unprivileged User Namespaces have been enabled by default in latest kernel update.
# cat /proc/sys/kernel/unprivileged_userns_clone
1
Is this a change in Arch policy or was the change unintentional?
Just curious.
Offline
Offline
And still there in kernel 5.1.9 so this seems to be intentional and no accident.
It would appear the "general security concerns" mentioned in the wiki [1] are no longer considered an issue. Fair enough.
[1] https://wiki.archlinux.org/index.php/Li … (optional)
Last edited by Toolybird (2019-06-11 22:10:03)
Offline
It would appear the "general security concerns" mentioned in the wiki [1] are no longer considered an issue. Fair enough.
They are still considered an issue, just not by linux package mantainer.
Offline
Unless I'm missing something, it appears Unprivileged User Namespaces have been enabled by default in latest kernel update.
# cat /proc/sys/kernel/unprivileged_userns_clone 1
Is this a change in Arch policy or was the change unintentional?
Just curious.
Yes, i think that's a bad thing anyway. Probably usability wins over security. :-(
Why not simply offer a special kernel for docker and co and leave it as it is ?
They are all bitches (in matter of lazyness)
On the other handy you can run your own PKGBUILD from Arch kernels and easy add this patch again. :-)
Regards
PS: i'm building my own kernels with Arch kernel sources always and my own patches ;-)
Last edited by Akusari (2019-06-13 14:05:00)
black listed users: seth WorMzy
Please stay away from this thread - Thanks.
Offline
No need to go through the trouble of patching for this. Just do the reverse of the enable instructions to disable it instead; set sysctl kernel.unprivileged_userns_clone=0 instead of 1.
Offline
No need to go through the trouble of patching for this. Just do the reverse of the enable instructions to disable it instead; set sysctl kernel.unprivileged_userns_clone=0 instead of 1.
Yes, that's possible of course and maybe the best way for folks out there. :-)
Well, It's always a matter of taste which way do you prefer and which "basic" compile-time setting should be enabled . ;-)
Just for example my kernel line looks like so: ".....pti=off spectre_v2=off spectre_v2_user=off spec_store_bypass_disable=off l1tf=off mds=off vga=792 audit=0 noresume"
WTF are doing this guy ??? Right, there are much better ways to handle that, specialy the new migration option. I have my reasons why i like it exactly this way!
Simply i prefer a kernel which is compile-time configured, expect meltdown and specture related staff. :-) It simply reduce the possibilities of configuration mistakes ;-)
And we are all humans ;-)
Last edited by Akusari (2019-06-13 14:49:33)
black listed users: seth WorMzy
Please stay away from this thread - Thanks.
Offline