Date: Thu, 28 Jan 2016 15:41:19 +0100 From: Robert Święcki <robert@...ecki.net> To: "Eric W. Biederman" <ebiederm@...ssion.com> Cc: Kees Cook <keescook@...omium.org>, Serge Hallyn <serge.hallyn@...ntu.com>, "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, Andy Lutomirski <luto@...capital.net>, Andrew Morton <akpm@...ux-foundation.org>, Al Viro <viro@...iv.linux.org.uk>, Richard Weinberger <richard@....at>, Dmitry Vyukov <dvyukov@...gle.com>, David Howells <dhowells@...hat.com>, Kostya Serebryany <kcc@...gle.com>, Alexander Potapenko <glider@...gle.com>, Eric Dumazet <edumazet@...gle.com>, Sasha Levin <sasha.levin@...cle.com>, "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Re: Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled >> The admin of such a machine could have disabled userns months earlier >> and limited the scope of the attack. > > Of course for the paranoid there is already a mechanism to do this. > /sbin/chroot. > > No new user namespaces are allowed to be created inside of a chroot. Another alternative is to create a custom kernel module which will disable the user namespace (by limiting to privileged users only, or disabling it altogether). IMO people tend to use distro kernels for convenience, and a suggestion of creating a chroot dir for every service exposed to users, or building a custom kernel module is an advice that not many sysadmins using distro kernels would take, even if they have concerns about the the increased attack surface enabled by CLONE_NEWUSER. Also, I don't think the willingness to disable the feature or limit it to the already privileged users will be something that only truly paranoid sysadmins/users would have. We've seen a fair amount of privilege escalation / DoS bugs that this kernel feature enabled in the recent 18 months or so, and they still seem to be found on a somewhat regular basis. Therefore this discussion and its outcome might be of interest to less paranoid folk as well. I agree with Kees that the "knob" will be mostly used by admins of web-servers (and similar services) as a protection against privilege escalation after getting low-priv code execution on the system. Therefore a sysctl enabled from /etc/sysctl.conf should work well here, even if it's set to the permissive mode by default at boot.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.