[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.
