Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp4893899imm; Tue, 9 Oct 2018 06:52:17 -0700 (PDT) X-Google-Smtp-Source: ACcGV61ozXIQ453idR/3j2RRgQKrJ0W+44iZyhR4AJDqYxEXoK70LqEiMD7kCtAErh5YWDuYX5GF X-Received: by 2002:a63:541e:: with SMTP id i30-v6mr25981898pgb.413.1539093137056; Tue, 09 Oct 2018 06:52:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539093137; cv=none; d=google.com; s=arc-20160816; b=d6joH4wTCzlStw2euXf8nHsP3M7JsxJ7IP7C1ij7OtorI29KVGgX4khu0eXffKxtYm 9eTBvXgb1Kch1RwebpKRNHxchyYeen9jtPy1Bz8goBW49Vgc5i7cIkuZZPLYKB4Bquky estBfvkAlpiNZr5Gam3vqHQg8rHiWsUiTjbd3oQtBDHzYuW58W7+QOWN2MEg3i7e1bRu CzSqQk0+BDpr/y9y4GTEs8KER3NizqymwKf1EEM0pUKh2+7ewqcRTiit9MGKnjV0M4eH XDwQyGZCzIC+1b+32yV+nAeVDabb79LJmqB6rAjkpYYqg3bJf8tYky1MPYTTL+nNfhK9 Pwmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=gPy7UKqolrRPivUJOqM7tolFGM7aL9jO+6tsh4SEzPQ=; b=OcIZTs1t3TJzAEw/qp8M10zC/n7wk5aQDdidz2Mou0edgBNlIRNRJ/pgr1Nyu+yiWJ EQWQCxmjfAfqBEYwg8BuScz7n+1vV5ZfqBGgEw6cj9nSlomsZ+dFgKNEURQ+6hYf5JbK PgP22W5xlIDqfv7LsaK0SIh1L7kLCdyWbzWJWpDNE+WkgVKAXMXGtIomweUUXTXgwtUj E5ifpDd9f3SrkJaADPDqbD/wlO9AMGY+YxqLdsZ05nXWzQOBKyBgwZQTqacuSER/DTBy XUQQyFnmhdgUKxR3rnW5dv99jQulgUa1j/yh8jHDwlMAJHxP4ZaqFmI5zSZfWNzBOiUo Hbzw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=LFzoWEmq; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z27-v6si19054407pgk.297.2018.10.09.06.52.02; Tue, 09 Oct 2018 06:52:17 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=LFzoWEmq; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726918AbeJIVIX (ORCPT + 99 others); Tue, 9 Oct 2018 17:08:23 -0400 Received: from mail-oi1-f195.google.com ([209.85.167.195]:39682 "EHLO mail-oi1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726503AbeJIVIX (ORCPT ); Tue, 9 Oct 2018 17:08:23 -0400 Received: by mail-oi1-f195.google.com with SMTP id y81-v6so1261473oia.6 for ; Tue, 09 Oct 2018 06:51:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gPy7UKqolrRPivUJOqM7tolFGM7aL9jO+6tsh4SEzPQ=; b=LFzoWEmqBoB6xzQyfv+myh49xVOknO+Kcmsf2193DRi8+SC+zWQnWseMYgt1U+TCj7 wNvLp21nkqb5RuPrfa0FcMYheIFG+/6W+yLXsPQvz53FuhFn7agOjfEu5ZLhC1kuFcfv 9DgEZ6B71hIY1oMLuuPUuL6CNB51EfyVOnkCLjCHfLOax/bFU+u96xhZFJ8Qz6Qaw7QO ujjSlEkza/Kd7r9tOHPOqooMFFfghpfqhK9aRKvt9xEePNsFmpxbVwE/srOxo/pGzeel 4Tyj6UjA3KDbIfMcoIwjdpHX7iqlYcBHBMR3eMsQ8YwN92w3MqjJYPKdKu5WvrHBgdLN QsBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gPy7UKqolrRPivUJOqM7tolFGM7aL9jO+6tsh4SEzPQ=; b=QyucMKcUlk8gUt0D4744qr+ylXPk6MUfQ772Ogkw/uVeC2ZDF4zwZGtONbQS5g4D+t zLAuEmrLQ0Oaau3m3Zht8blaZm55RlPS+Q8/rw5ZBLZWYVJ+zCci0Tjlq+GazZtuj/90 Aieqn8XRSboBnADI6bIZw99HqEYUcniFT/TiiXdWZknXBdtJmyr87ZetPmydeyZeeMFG wVivZ30xmX2a8iZqC3EczI0CpRgnpoIaWfptgGfMXj+FUVq4ILuTOFnUeU6+w1e0fQVP VkJUFfU/FUsbXGiiGCClFnduLWmVwp/BFitZIdhSo8GDiOdpUcJ4F4FLukDuoNZhC0uX 0C2Q== X-Gm-Message-State: ABuFfojSU014E8luabwrKtOSfuq/n6woy0Sp5i+MO9iVzyrHdenXm6tR W2Vc22R1VcvPKC/E5zCTsLP5BmjSnRY3xiGL65gDSA== X-Received: by 2002:aca:bf55:: with SMTP id p82-v6mr7399079oif.39.1539093079425; Tue, 09 Oct 2018 06:51:19 -0700 (PDT) MIME-Version: 1.0 References: <20180927151119.9989-1-tycho@tycho.ws> <20180927151119.9989-4-tycho@tycho.ws> <20181008151629.hkgzzsluevwtuclw@brauner.io> <20181008162147.ubfxxsv2425l2zsp@brauner.io> <20181008181815.pwnqxngj22mhm2vj@brauner.io> <20181009132850.fp6yne2vgmfpi27k@brauner.io> <20181009134923.2fvf5roghqgaj5gq@brauner.io> In-Reply-To: <20181009134923.2fvf5roghqgaj5gq@brauner.io> From: Jann Horn Date: Tue, 9 Oct 2018 15:50:53 +0200 Message-ID: Subject: Re: [PATCH v7 3/6] seccomp: add a way to get a listener fd from ptrace To: christian@brauner.io Cc: Tycho Andersen , Kees Cook , Linux API , containers@lists.linux-foundation.org, suda.akihiro@lab.ntt.co.jp, Oleg Nesterov , kernel list , "Eric W. Biederman" , linux-fsdevel@vger.kernel.org, Christian Brauner , Andy Lutomirski , linux-security-module , selinux@tycho.nsa.gov, Paul Moore , Stephen Smalley , Eric Paris Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 9, 2018 at 3:49 PM Christian Brauner wrote: > > On Tue, Oct 09, 2018 at 03:36:04PM +0200, Jann Horn wrote: > > +cc selinux people explicitly, since they probably have opinions on this > > > > On Tue, Oct 9, 2018 at 3:29 PM Christian Brauner wrote: > > > On Tue, Oct 09, 2018 at 02:39:53PM +0200, Jann Horn wrote: > > > > On Mon, Oct 8, 2018 at 8:18 PM Christian Brauner wrote: > > > > > On Mon, Oct 08, 2018 at 06:42:00PM +0200, Jann Horn wrote: > > > > > > On Mon, Oct 8, 2018 at 6:21 PM Christian Brauner wrote: > > > > > > > On Mon, Oct 08, 2018 at 05:33:22PM +0200, Jann Horn wrote: > > > > > > > > On Mon, Oct 8, 2018 at 5:16 PM Christian Brauner wrote: > > > > > > > > > On Thu, Sep 27, 2018 at 09:11:16AM -0600, Tycho Andersen wrote: > > > > > > > > > > diff --git a/kernel/seccomp.c b/kernel/seccomp.c > > > > > > > > > > index 44a31ac8373a..17685803a2af 100644 > > > > > > > > > > --- a/kernel/seccomp.c > > > > > > > > > > +++ b/kernel/seccomp.c > > > > > > > > > > @@ -1777,4 +1777,35 @@ static struct file *init_listener(struct task_struct *task, > > > > > > > > > > > > > > > > > > > > return ret; > > > > > > > > > > } > > > > > > > > > > + > > > > > > > > > > +long seccomp_new_listener(struct task_struct *task, > > > > > > > > > > + unsigned long filter_off) > > > > > > > > > > +{ > > > > > > > > > > + struct seccomp_filter *filter; > > > > > > > > > > + struct file *listener; > > > > > > > > > > + int fd; > > > > > > > > > > + > > > > > > > > > > + if (!capable(CAP_SYS_ADMIN)) > > > > > > > > > > + return -EACCES; > > > > > > > > > > > > > > > > > > I know this might have been discussed a while back but why exactly do we > > > > > > > > > require CAP_SYS_ADMIN in init_userns and not in the target userns? What > > > > > > > > > if I want to do a setns()fd, CLONE_NEWUSER) to the target process and > > > > > > > > > use ptrace from in there? > > > > > > > > > > > > > > > > See https://lore.kernel.org/lkml/CAG48ez3R+ZJ1vwGkDfGzKX2mz6f=jjJWsO5pCvnH68P+RKO8Ow@mail.gmail.com/ > > > > > > > > . Basically, the problem is that this doesn't just give you capability > > > > > > > > over the target task, but also over every other task that has the same > > > > > > > > filter installed; you need some sort of "is the caller capable over > > > > > > > > the filter and anyone who uses it" check. > > > > > > > > > > > > > > Thanks. > > > > > > > But then this new ptrace feature as it stands is imho currently broken. > > > > > > > If you can install a seccomp filter with SECCOMP_RET_USER_NOTIF if you > > > > > > > are ns_cpabable(CAP_SYS_ADMIN) and also get an fd via seccomp() itself > > > > > > > if you are ns_cpabable(CAP_SYS_ADMIN) > > > > > > > > Actually, you don't need CAP_SYS_ADMIN for seccomp() at all as long as > > > > you enable the NNP flag, I think? > > > > > > Yes, if you turn on NNP you don't even need sys_admin. > > > > > > > > > > > > > > then either the new ptrace() api > > > > > > > extension should be fixed to allow for this too or the seccomp() way of > > > > > > > retrieving the pid - which I really think we want - needs to be fixed to > > > > > > > require capable(CAP_SYS_ADMIN) too. > > > > > > > The solution where both require ns_capable(CAP_SYS_ADMIN) is - imho - > > > > > > > the preferred way to solve this. > > > > > > > Everything else will just be confusing. > > > > > > > > > > > > First you say "broken", then you say "confusing". Which one do you mean? > > > > > > > > > > Both. It's broken in so far as it places a seemingly unnecessary > > > > > restriction that could be fixed. You outlined one possible fix yourself > > > > > in the link you provided. > > > > > > > > If by "possible fix" you mean "check whether the seccomp filter is > > > > only attached to a single task": That wouldn't fundamentally change > > > > the situation, it would only add an additional special case. > > > > > > > > > And it's confusing in so far as there is a way > > > > > via seccomp() to get the fd without said requirement. > > > > > > > > I don't find it confusing at all. seccomp() and ptrace() are very > > > > > > Fine, then that's a matter of opinion. I find it counterintuitive that > > > you can get an fd without privileges via one interface but not via > > > another. > > > > > > > different situations: When you use seccomp(), infrastructure is > > > > > > Sure. Note, that this is _one_ of the reasons why I want to make sure we > > > keep the native seccomp() only based way of getting an fd without > > > forcing userspace to switching to a differnet kernel api. > > > > > > > already in place for ensuring that your filter is only applied to > > > > processes over which you are capable, and propagation is limited by > > > > inheritance from your task down. When you use ptrace(), you need a > > > > pretty different sort of access check that checks whether you're > > > > privileged over ancestors, siblings and so on of the target task. > > > > > > So, don't get me wrong I'm not arguing against the ptrace() interface in > > > general. If this is something that people find useful, fine. But, I > > > would like to have a simple single-syscall pure-seccomp() based way of > > > getting an fd, i.e. what we have in patch 1 of this series. > > > > Yeah, I also prefer the seccomp() one. > > > > > > But thinking about it more, I think that CAP_SYS_ADMIN over the saved > > > > current->mm->user_ns of the task that installed the filter (stored as > > > > a "struct user_namespace *" in the filter) should be acceptable. > > > > > > Hm... Why not CAP_SYS_PTRACE? > > > > Because LSMs like SELinux add extra checks that apply even if you have > > CAP_SYS_PTRACE, and this would subvert those. The only capability I > > know of that lets you bypass LSM checks by design (if no LSM blocks > > the capability itself) is CAP_SYS_ADMIN. > > > > > One more thing. Citing from [1] > > > > > > > I think there's a security problem here. Imagine the following scenario: > > > > > > > > 1. task A (uid==0) sets up a seccomp filter that uses SECCOMP_RET_USER_NOTIF > > > > 2. task A forks off a child B > > > > 3. task B uses setuid(1) to drop its privileges > > > > 4. task B becomes dumpable again, either via prctl(PR_SET_DUMPABLE, 1) > > > > or via execve() > > > > 5. task C (the attacker, uid==1) attaches to task B via ptrace > > > > 6. task C uses PTRACE_SECCOMP_NEW_LISTENER on task B > > > > > > Sorry, to be late to the party but would this really pass > > > __ptrace_may_access() in ptrace_attach()? It doesn't seem obvious to me > > > that it would... Doesn't look like it would get past: > > > > > > tcred = __task_cred(task); > > > if (uid_eq(caller_uid, tcred->euid) && > > > uid_eq(caller_uid, tcred->suid) && > > > uid_eq(caller_uid, tcred->uid) && > > > gid_eq(caller_gid, tcred->egid) && > > > gid_eq(caller_gid, tcred->sgid) && > > > gid_eq(caller_gid, tcred->gid)) > > > goto ok; > > > if (ptrace_has_cap(tcred->user_ns, mode)) > > > goto ok; > > > rcu_read_unlock(); > > > return -EPERM; > > > ok: > > > rcu_read_unlock(); > > > mm = task->mm; > > > if (mm && > > > ((get_dumpable(mm) != SUID_DUMP_USER) && > > > !ptrace_has_cap(mm->user_ns, mode))) > > > return -EPERM; > > > > Which specific check would prevent task C from attaching to task B? If > > the UIDs match, the first "goto ok" executes; and you're dumpable, so > > you don't trigger the second "return -EPERM". > > You'd also need CAP_SYS_PTRACE in the mm->user_ns which you shouldn't > have if you did a setuid to an unpriv user. (But I always find that code > confusing.) Only if the target hasn't gone through execve() since setuid().