Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled
[Posted January 26, 2016 by corbet]
| From: |
| Andy Lutomirski <luto-AT-amacapital.net> |
| To: |
| "Eric W. Biederman" <ebiederm-AT-xmission.com> |
| Subject: |
| Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled |
| Date: |
| Sun, 24 Jan 2016 14:22:19 -0800 |
| Message-ID: |
| <CALCETrWYRvqhyCwx5RX6L3TEYCfW0j6ThFUc+ASL7BpxgO5dEQ@mail.gmail.com> |
| Cc: |
| Kees Cook <keescook-AT-chromium.org>, Andrew Morton <akpm-AT-linux-foundation.org>, Al Viro <viro-AT-zeniv.linux.org.uk>, Richard Weinberger <richard-AT-nod.at>, =?UTF-8?B?Um9iZXJ0IMWad2nEmWNraQ==?= <robert-AT-swiecki.net>, Dmitry Vyukov <dvyukov-AT-google.com>, David Howells <dhowells-AT-redhat.com>, Miklos Szeredi <mszeredi-AT-suse.cz>, Kostya Serebryany <kcc-AT-google.com>, Alexander Potapenko <glider-AT-google.com>, Eric Dumazet <edumazet-AT-google.com>, Sasha Levin <sasha.levin-AT-oracle.com>, "linux-doc-AT-vger.kernel.org" <linux-doc-AT-vger.kernel.org>, "linux-kernel-AT-vger.kernel.org" <linux-kernel-AT-vger.kernel.org>, "kernel-hardening-AT-lists.openwall.com" <kernel-hardening-AT-lists.openwall.com> |
| Archive‑link: | |
Article |
On Fri, Jan 22, 2016 at 7:02 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> Kees Cook <keescook@chromium.org> writes:
>
>> There continues to be unexpected side-effects and security exposures
>> via CLONE_NEWUSER. For many end-users running distro kernels with
>> CONFIG_USER_NS enabled, there is no way to disable this feature when
>> desired. As such, this creates a sysctl to restrict CLONE_NEWUSER so
>> admins not running containers or Chrome can avoid the risks of this
>> feature.
>
> I don't actually think there do continue to be unexpected side-effects
> and security exposures with CLONE_NEWUSER. It takes a while for all of
> the fixes to trickle out to distros. At most what I have seen recently
> are problems with other kernel interfaces being amplified with user
> namespaces. AKA the current mess with devpts, and the unexpected
> issues with bind mounts in mount namespaces.
>
>
> So to keep this productive. Please tell me about the threat model
> you envision, and how you envision knobs in the kernel being used to
> counter those threats.
I consider the ability to use CLONE_NEWUSER to acquire CAP_NET_ADMIN
over /any/ network namespace and to thus access the network
configuration API to be a huge risk. For example, unprivileged users
can program iptables. I'll eat my hat if there are no privilege
escalations in there. (They can't request module loading, but still.)
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
