[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1445258180.4099.18.camel@debian.org>
Date: Mon, 19 Oct 2015 14:36:20 +0200
From: Yves-Alexis Perez <corsac@...ian.org>
To: "Serge E. Hallyn" <serge@...lyn.com>,
Tobias Markus <tobias@...lix.eu>
Cc: linux-kernel@...r.kernel.org,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Al Viro <viro@...IV.linux.org.uk>,
Serge Hallyn <serge.hallyn@...onical.com>,
Andrew Morton <akpm@...uxfoundation.org>,
Andy Lutomirski <luto@...capital.net>,
Christoph Lameter <cl@...ux.com>,
"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>,
linux-security-module@...r.kernel.org, linux-api@...r.kernel.org,
linux-man@...r.kernel.org,
Richard Weinberger <richard.weinberger@...il.com>
Subject: Re: [PATCH] userns/capability: Add user namespace capability
On dim., 2015-10-18 at 20:41 -0500, Serge E. Hallyn wrote:
> We shouldn't need a long-term solution. Your concern is bugs. After
> some time surely we'll feel that we have achieved a stable solution?
But this is actually the whole point: we need a long term solution, because
they will always be bug, whether in user namespaces or in others parts exposed
by user namespaces. It's fine to fix them when we find them, but that still
means they're exploitable even before we know about them. We still find bugs
in code written years ago, it's quite certain there are bugs in current code.
User namespaces are a way to expose more interfaces to unprivileged users,
interfaces which weren't designed to be exposed like that. In a way that's the
opposite of seccomp. That doesn't make it bad, obviously, but that still means
having a way to control it finely could be helpful.
Regards,
--
Yves-Alexis
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists