From: Richard Weinberger <richard@nod.at>
To: Tobias Markus <tobias@miglix.eu>
Cc: LKML <linux-kernel@vger.kernel.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Serge Hallyn <serge.hallyn@canonical.com>,
Andrew Morton <akpm@linuxfoundation.org>,
Andy Lutomirski <luto@amacapital.net>,
Christoph Lameter <cl@linux.com>,
"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>,
LSM <linux-security-module@vger.kernel.org>,
"open list:ABI/API" <linux-api@vger.kernel.org>,
linux-man <linux-man@vger.kernel.org>
Subject: Re: [PATCH] userns/capability: Add user namespace capability
Date: Mon, 19 Oct 2015 00:06:38 +0200 [thread overview]
Message-ID: <562417EE.4070602@nod.at> (raw)
In-Reply-To: <562413FD.2020401@miglix.eu>
Am 18.10.2015 um 23:49 schrieb Tobias Markus:
> But before we continue arguing endlessly, I just got an idea: What about
> adding a sysctl to enable/disable enforcement of the hypothetical
> CAP_SYS_USER_NS, just like with /proc/sys/kernel/kptr_restrict and
> CAP_SYSLOG? Would also prevent any potential userspace breakage.
My argument stands, hiding user namespaces behind whatever
switch and rendering it into a second class citizen does not improve its security.
Especially ad-hoc solutions are not expedient. Reducing the attack surface must not
lead to gazillions of new capabilities, sysctl switches, etc...
user namespaces are neither the first nor the last "critical" kernel feature.
I'm sure RHEL will ship a SELinux boolean to disable user namespaces as they do
for many other OS features. This is fine and exactly why we have LSM.
Thanks,
//richard
next prev parent reply other threads:[~2015-10-18 22:06 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-17 15:58 [PATCH] userns/capability: Add user namespace capability Tobias Markus
2015-10-17 20:17 ` Richard Weinberger
2015-10-18 20:13 ` Tobias Markus
2015-10-18 20:21 ` Richard Weinberger
2015-10-18 20:41 ` Tobias Markus
2015-10-18 20:48 ` Richard Weinberger
2015-10-18 21:49 ` Tobias Markus
2015-10-18 22:06 ` Richard Weinberger [this message]
2015-10-19 0:28 ` Mike Frysinger
2015-10-17 21:55 ` Serge E. Hallyn
2015-10-18 20:13 ` Tobias Markus
2015-10-19 1:41 ` Serge E. Hallyn
2015-10-19 12:36 ` Yves-Alexis Perez
2015-10-19 12:48 ` Richard Weinberger
2015-10-22 20:45 ` Eric W. Biederman
2015-10-22 21:02 ` Andy Lutomirski
2015-10-22 21:44 ` Eric W. Biederman
2015-10-19 14:24 ` Austin S Hemmelgarn
2015-10-21 18:53 ` Andy Lutomirski
2015-10-21 19:13 ` Austin S Hemmelgarn
2015-10-22 17:10 ` Andy Lutomirski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=562417EE.4070602@nod.at \
--to=richard@nod.at \
--cc=akpm@linuxfoundation.org \
--cc=cl@linux.com \
--cc=ebiederm@xmission.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mtk.manpages@gmail.com \
--cc=serge.hallyn@canonical.com \
--cc=tobias@miglix.eu \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).