linux-man.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tobias Markus <tobias-gyUQdkDHmHmHXe+LvDLADg@public.gmane.org>
To: Richard Weinberger <richard-/L3Ra7n9ekc@public.gmane.org>
Cc: LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"Eric W. Biederman"
	<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>,
	Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
	Serge Hallyn
	<serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>,
	Andrew Morton
	<akpm-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
	Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>,
	Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org>,
	"Michael Kerrisk (man-pages)"
	<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	LSM
	<linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"open list:ABI/API"
	<linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-man <linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH] userns/capability: Add user namespace capability
Date: Sun, 18 Oct 2015 22:41:11 +0200	[thread overview]
Message-ID: <562403E7.6070300@miglix.eu> (raw)
In-Reply-To: <5623FF36.8080800-/L3Ra7n9ekc@public.gmane.org>

On 18.10.2015 22:21, Richard Weinberger wrote:
> Am 18.10.2015 um 22:13 schrieb Tobias Markus:
>> On 17.10.2015 22:17, Richard Weinberger wrote:
>>> On Sat, Oct 17, 2015 at 5:58 PM, Tobias Markus <tobias-gyUQdkDHmHmHXe+LvDLADg@public.gmane.org> wrote:
>>>> One question remains though: Does this break userspace executables that
>>>> expect being able to create user namespaces without priviledge? Since
>>>> creating user namespaces without CAP_SYS_ADMIN was not possible before
>>>> Linux 3.8, programs should already expect a potential EPERM upon calling
>>>> clone. Since creating a user namespace without CAP_SYS_USER_NS would
>>>> also cause EPERM, we should be on the safe side.
>>>
>>> In case of doubt, yes it will break existing software.
>>> Hiding user namespaces behind CAP_SYS_USER_NS will not magically
>>> make them secure.
>>>
>> The goal is not to make user namespaces secure, but to limit access to
>> them somewhat in order to reduce the potential attack surface.
> 
> We have already a framework to reduce the attack surface, seccomp.
> There is no need to invent new capabilities for every non-trivial
> kernel feature.
> 
> I can understand the user namespaces seems scary and had bugs.
> But which software didn't?
> 
> Are there any unfixed exploitable bugs in user namespaces in recent kerenls?
> 
> Thanks,
> //richard

Isn't seccomp about setting a per-thread syscall filter? Correct me if
I'm wrong, but I don't know of any way of using seccomp to globally ban
the use of clone or unshare with CLONE_NEWUSER except for a few
whiteliste executables, and that's the idea of this hypothetical capability.

Sure, there are no known exploitable bugs in recent kernels, but would
you guarantee that for the next 10 years? Every software has bugs, some
of them exploitable, no amount of testing can prevent that. I'm not
paranoid, but on the other hand, why should every Linux user having
CONFIG_USER_NS enabled have to expose more attack surface than he
absolutely has to?

Richard, would you run an Apache HTTP server exposed to the internet on
your own laptop, without any security precautions? According to your
reasoning, Apache is surely scary and has many bugs, but every software
has bugs, right?

I really don't want to introduce a user-facing API change just for the
fun of it - so if there's any better way to do this, please tell me.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2015-10-18 20:41 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
     [not found] ` <5622700C.9090107-gyUQdkDHmHmHXe+LvDLADg@public.gmane.org>
2015-10-17 20:17   ` Richard Weinberger
2015-10-18 20:13     ` Tobias Markus
     [not found]       ` <5623FD86.2030609-gyUQdkDHmHmHXe+LvDLADg@public.gmane.org>
2015-10-18 20:21         ` Richard Weinberger
     [not found]           ` <5623FF36.8080800-/L3Ra7n9ekc@public.gmane.org>
2015-10-18 20:41             ` Tobias Markus [this message]
2015-10-18 20:48               ` Richard Weinberger
     [not found]                 ` <56240599.3050903-/L3Ra7n9ekc@public.gmane.org>
2015-10-18 21:49                   ` Tobias Markus
2015-10-18 22:06                     ` Richard Weinberger
2015-10-19  0:28         ` Mike Frysinger
2015-10-17 21:55   ` Serge E. Hallyn
     [not found]     ` <20151017215501.GA22900-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2015-10-18 20:13       ` Tobias Markus
     [not found]         ` <5623FD82.4030902-gyUQdkDHmHmHXe+LvDLADg@public.gmane.org>
2015-10-19  1:41           ` Serge E. Hallyn
     [not found]             ` <20151019014112.GA1683-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2015-10-19 12:36               ` Yves-Alexis Perez
     [not found]                 ` <1445258180.4099.18.camel-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
2015-10-19 12:48                   ` Richard Weinberger
2015-10-22 20:45           ` Eric W. Biederman
     [not found]             ` <87twpi63ai.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2015-10-22 21:02               ` Andy Lutomirski
     [not found]                 ` <CALCETrWKN+Uzw_TYqVTGatNZ3LT5RbSM1WuYPoXeKQs9Yw_qjg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-10-22 21:44                   ` Eric W. Biederman
2015-10-19 14:24   ` Austin S Hemmelgarn
     [not found]     ` <5624FD3B.2050401-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-10-21 18:53       ` Andy Lutomirski
     [not found]         ` <CALCETrWfZ9hXvLPtJnZhU-ZdoUbYNo-QSydMPvP6Q7Rp0oCQaw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
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=562403E7.6070300@miglix.eu \
    --to=tobias-gyuqdkdhmhmhxe+lvdladg@public.gmane.org \
    --cc=akpm-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
    --cc=cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org \
    --cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org \
    --cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org \
    --cc=mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=richard-/L3Ra7n9ekc@public.gmane.org \
    --cc=serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org \
    --cc=viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org \
    /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).