Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp881656imm; Wed, 10 Oct 2018 05:55:45 -0700 (PDT) X-Google-Smtp-Source: ACcGV60BaizNtKmJHBiBrIK5Wtb+KVZcv17y7oHgCt6fhJWPuLLAmUAi5gmbAWrqrxZQ5QY1N6Zf X-Received: by 2002:a63:9304:: with SMTP id b4-v6mr14770213pge.36.1539176145257; Wed, 10 Oct 2018 05:55:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539176145; cv=none; d=google.com; s=arc-20160816; b=OF8XoTEKjlhVIHJAOAugDEqzCsqlYxBbGyJ5S+Stfpu8Lxk+W4SG4Vy0FPad4WRvGg 1Ytu0b9WOWoOI6SmVd2qZiRsQGDID2snMrXozwj6lARLlS4ap+kNddI20jNpuuledIBN HQeVNO8gRc3PemRn/MiC4H3NzyCHcmXYfYrAsvhRcIK4k7fuTNkaZI24eGD/0uzfBvaf YwXD3Cr+804+4C+M387cd3Wamj5xGYLyEAldv4HqWeGjVwK2oYsQ17rMfVNbyXih5Ypi eGqP1KTR8v2jMG4L6f+dPcU4XFpRq0MjmFPVZyBQLfZXr+BZ34k888tre47sr3syZi38 xKbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=o0QQLJyuUGQBkShWfur6HYVlqSi+2uf09NLluUqG41k=; b=qNNIWZSaFqwvEBIXudYPSxPrYA/7PLbRsO69+PUZgCPxybFlFT97MCsn+XuD2ZiS8T fTnR0BrUqZrynVWlO2YLXZJjTWhHjYxIIz8wpKdo+T7wCCRVl0GQZGdiUgZndlxGCBDi L9KTDax4XSDr55LJqCa7AWy3ZvuM0+IYuENixEDHHm9iBS8GGziCLrSUQ1e6FlIC0fD5 rj5BA4rSM/haFOqK3V3N33BmKrxSoijw5c1UEQSTUpmp8V8QQc7xfMGaHqEBBE2AFq0R 4O9ax0CATSkjEHKSBjA2vnLnFv8Xh0CpgmGna9OQQVR390s1uMM+eJJAx1dq/23rOISH CRFw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@brauner.io header.s=google header.b=Ayl6kyH8; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 31-v6si26585082plj.160.2018.10.10.05.55.30; Wed, 10 Oct 2018 05:55:45 -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=@brauner.io header.s=google header.b=Ayl6kyH8; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726936AbeJJUQi (ORCPT + 99 others); Wed, 10 Oct 2018 16:16:38 -0400 Received: from mail-wm1-f65.google.com ([209.85.128.65]:36909 "EHLO mail-wm1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726861AbeJJUQh (ORCPT ); Wed, 10 Oct 2018 16:16:37 -0400 Received: by mail-wm1-f65.google.com with SMTP id 185-v6so5652885wmt.2 for ; Wed, 10 Oct 2018 05:54:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brauner.io; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=o0QQLJyuUGQBkShWfur6HYVlqSi+2uf09NLluUqG41k=; b=Ayl6kyH88HqPGMjfcmRfuOGkCYPMjBnoDdI7GCNNg9fj+qekPYSMwjuiNUOOzcEJTK EodIOqkhIcPhiVOXG9Yb52gdh3cko1SXbSr6h2lXsBiqobKHfXpFWkFlpwU+hF2RH3Wp kMqUPix3XBhM+twn4eEGs/+Tp5SJv+Iab8qLYjY3DfUUYzYleoXdz+OrhYf6oodeckQ4 cJY/gGrUkVJ6CQLOPcPP4DiXPwIhL2N8cBK+i/0DFJUbMUUrCHO2wHiSt6wVEj6DYa+y 92TghvF4YapmkXmf7910l7rU8G/PJGpwadWikKLMaVAS5InHv3b+5hTdxxozpbpdmKyQ dR1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=o0QQLJyuUGQBkShWfur6HYVlqSi+2uf09NLluUqG41k=; b=XYUfqutUnyXzF9pjYPRE+eSSrfdhPmVqyckO3QZnPV1028nRVWvm8yRb/lSflatTEu Z2QpifjtDCqZSXZNyVXrlSGMThvd49PPW8wUVPrqoSAgJx/a4yQdd/y/NfsUSJI3VG5v 728XuqLRhJ5ziKumHZgGTtUzckLzdSi+XSKsqdY1EvX4iIZgEZNLUAodlJXDBQVoMGcC IQ+EGO9HvOgAjy2BfJ71v9tz0pFsz3R0AsuT+qKAqF+Yz3GshEvllCjoejMxqlUcPl2i dQ/IgtqcHH1yai5lZMAhlOddXL+gijUMV9puwGXQTtQV+oGN0g2nqNTLuhuygC+WRUlz QhQQ== X-Gm-Message-State: ABuFfojrURtqWjStvwMsY5eI8swKKvHBwbdbrnmsVv3o4hBKMTqkBtFp v1gb2Hn4FuRGBMXWA5uI22/ziA== X-Received: by 2002:a1c:3795:: with SMTP id e143-v6mr850432wma.9.1539176071111; Wed, 10 Oct 2018 05:54:31 -0700 (PDT) Received: from brauner.io ([2a02:8070:8895:9700:8197:8849:535a:4f00]) by smtp.gmail.com with ESMTPSA id x66-v6sm6110731wme.35.2018.10.10.05.54.29 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 10 Oct 2018 05:54:30 -0700 (PDT) Date: Wed, 10 Oct 2018 14:54:23 +0200 From: Christian Brauner To: Jann Horn 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 Subject: Re: [PATCH v7 3/6] seccomp: add a way to get a listener fd from ptrace Message-ID: <20181010125422.rouslofknxzvygzr@brauner.io> References: <20181008181815.pwnqxngj22mhm2vj@brauner.io> <20181009132850.fp6yne2vgmfpi27k@brauner.io> <20181009134923.2fvf5roghqgaj5gq@brauner.io> <20181009140932.e5w5lgbgucbl72kt@brauner.io> <20181009162022.d7fd2wibyq6xi6sg@brauner.io> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 09, 2018 at 06:26:47PM +0200, Jann Horn wrote: > On Tue, Oct 9, 2018 at 6:20 PM Christian Brauner wrote: > > On Tue, Oct 09, 2018 at 05:26:26PM +0200, Jann Horn wrote: > > > On Tue, Oct 9, 2018 at 4:09 PM Christian Brauner wrote: > > > > On Tue, Oct 09, 2018 at 03:50:53PM +0200, Jann Horn wrote: > > > > > 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: > > > > > > > On Tue, Oct 9, 2018 at 3:29 PM Christian Brauner wrote: > > > > > > > > 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(). > > > > > > > > Sorry if I want to know this in excessive detail but I'd like to > > > > understand this properly so bear with me :) > > > > - If task B has setuid()ed and prctl(PR_SET_DUMPABLE, 1)ed but not > > > > execve()ed then C won't pass ptrace_has_cap(mm->user_ns, mode). > > > > > > Yeah. > > > > > > > - If task B has setuid()ed, exeved()ed it will get its dumpable flag set > > > > to /proc/sys/fs/suid_dumpable > > > > > > Not if you changed all UIDs (e.g. by calling setuid() as root). In > > > that case, setup_new_exec() calls "set_dumpable(current->mm, > > > SUID_DUMP_USER)". > > > > Actually, looking at this when C is trying to PTRACE_ATTACH to B as an > > unprivileged user even if B execve()ed and it is dumpable C still > > wouldn't have CAP_SYS_PTRACE in the mm->user_ns unless it already is > > privileged over mm->user_ns which means it must be in an ancestor > > user_ns. > > Huh? Why would you need CAP_SYS_PTRACE for anything here? You can > ptrace another process running under your UID just fine, no matter > what the namespaces are. I'm not sure what you're saying. Sorry, I was out the door yesterday when answering this and was too brief. I forgot to mention: /proc/sys/kernel/yama/ptrace_scope. It should be enabled by default on nearly all distros and even if not - which is an administrators choice - you can usually easily enable it via sysctl. 1 ("restricted ptrace") [default value] When performing an operation that requires a PTRACE_MODE_ATTACH check, the calling process must either have the CAP_SYS_PTRACE capability in the user namespace of the target process or it must have a predeā€ fined relationship with the target process. By default, the predefined relationship is that the target process must be a descendant of the caller. If you don't have it set you're already susceptible to all kinds of other attacks and I'm still not convinced we need to bring out the big capable(CAP_SYS_ADMIN) gun here.