Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp2493166ybf; Mon, 2 Mar 2020 09:43:21 -0800 (PST) X-Google-Smtp-Source: ADFU+vvQLx5q5E2WO6HFiMVrMo5Q9DgNHI9tVzYvB//E/sFXUo/yqruFdv0AUH7txU2XzVukDjO9 X-Received: by 2002:aca:b1d5:: with SMTP id a204mr181304oif.82.1583171001759; Mon, 02 Mar 2020 09:43:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583171001; cv=none; d=google.com; s=arc-20160816; b=s+p+RqB199eFaDYI3hGAVwbgb0hhUeFdO92YfL0tl5pQvLVd4HbHC1niGsJmYczJQD bmdFbKyEEgHnV0mOmiNXfyJ0tCojATFjckVhT1vU63TZSFsAVDAGupHR2lFpK8KAP9U4 Fn9haCSqFO2l66qSFoplb0WgCWGHqPOzSl/5bKu/cn3whMdpDLwf3UftYTzroU5kvYQL opdKm6nOgVCwxbfuApsAtMaGxA0TxXXaoD5W2RSMFFUcsyTHT6NjNiQrI9fgwaK0xr0q BAsoQ+dVTh5wUPCb3QzOL35prCrcVd4QhAm5+pQ0W/Junr+Dajm7iG1ucFQ8/XPm/4Iv mv/Q== 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:content-transfer-encoding :mime-version:references:in-reply-to:user-agent:date:from:message-id :dkim-signature; bh=I9QbkrVVYHhIoSifcadeu1EkGLpO8eHQFkfllDR/K2c=; b=t73SseZ8znKMO2Syyg9z+Q40DamGzfnz4A50TXVyKYztdE1fTEWj84P1pdRjlPOfwY rGV+U6b81p5zCEGM/Q5Js7bPxLqy2PM8t9GgkiPUZiB9v6GIKAIVdCuKbgb8f/nDwoui x+ZQjOOiqPEbNx2Hg7T8v9G9p0gCF73gF7DFbORO0DyFDCJIqYKYNCDLVtVCbyT/aO0U ecq0JzXdEiO1kdca0qVbRoJBDMAq9Foko+WZ1nub7Movpz1oivpmWc5GzmnjJ10PXE2o O4h+qR3EmF9yVyBvUf8YhQUqaubEPbrEVkkkhvUfVCbmXWhK0ag95yVR/raY/2rA/Zkj t49g== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@brauner.io header.s=google header.b="f0oD/nK5"; 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 b21si9319423ots.38.2020.03.02.09.43.09; Mon, 02 Mar 2020 09:43:21 -0800 (PST) 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=fail header.i=@brauner.io header.s=google header.b="f0oD/nK5"; 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 S1727417AbgCBRnE (ORCPT + 99 others); Mon, 2 Mar 2020 12:43:04 -0500 Received: from mail-wm1-f68.google.com ([209.85.128.68]:52697 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727366AbgCBRnD (ORCPT ); Mon, 2 Mar 2020 12:43:03 -0500 Received: by mail-wm1-f68.google.com with SMTP id p9so209690wmc.2 for ; Mon, 02 Mar 2020 09:43:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brauner.io; s=google; h=message-id:from:date:user-agent:in-reply-to:references:mime-version :content-transfer-encoding:subject:to:cc; bh=I9QbkrVVYHhIoSifcadeu1EkGLpO8eHQFkfllDR/K2c=; b=f0oD/nK5puQRTMWphzAe+fUjcl+QhqrVxCo/yA6SLJElb5NXYz9gSyZUxWwCdooL64 EL9J2cXo3+/hyx+w009TNArcZCCZ2lAmyKO8ssx5+yngWIyAUI0rHXMm2qy5M9qUEQVY p88BcddFHbuYjhgn96fRgpAxgjHaSRGOtQdU0BA81I9V+CnwPR4dQFRDP93fj+JW/Cbf Bb1bhdKCnBU4zukfA4g4ab5SJssq/TYd/QkgYUbGPABaMxgCBhErzfKfrYri+hXVP4HR ZgGcaDMuaaLq1HX1ZF8eeApGXLdzfZgDWEGnb0ySJ77RCGpErepUZ1dPfgVzr2NhlJ7/ DZAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:from:date:user-agent:in-reply-to :references:mime-version:content-transfer-encoding:subject:to:cc; bh=I9QbkrVVYHhIoSifcadeu1EkGLpO8eHQFkfllDR/K2c=; b=I9sNsbn3PukuuFCX+o3KzDUMFIQ4w+ErZA5MbZKPkhGbFUMhF7hjEjM1/ASSGlMWeV ReNJcm3aqqlq+VUAT6o3iqtp4OBC5fp/mM8v9ouYiV04Uy4nAaTRao6GsRKxKHI6k2Qn GcCHlI25OUZLTZaTXtDXi/n3W+1Wud2ezvnHY201cp/KUKFZM6Aa1uHqN4jsA6u8VaxG UFzXLltdAQvRMFWq3LjGOmISfBIV+DR1jBlaywXz9mHSOUtuxL9CGBGArnbiaSie/CBB k/PlDzQc0shoMNG/bW/3TkkfdL0OwH8TKlp9TMtAC1UV3Dznf1Epu+FrnZEjc8ZPyfu3 3zig== X-Gm-Message-State: ANhLgQ1R0IxYe+HYMR4ZthSSMBGydt91ppaG+uZOVCI3Cl9bPnMF+i+W inu3HyrfsdXOh4lYogTuFk6eLA== X-Received: by 2002:a1c:c2c5:: with SMTP id s188mr186830wmf.162.1583170980356; Mon, 02 Mar 2020 09:43:00 -0800 (PST) Received: from Google-Pixel-3a.fritz.box (ip5f5bf7ec.dynamic.kabel-deutschland.de. [95.91.247.236]) by smtp.gmail.com with ESMTPSA id z19sm120954wmi.43.2020.03.02.09.42.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Mar 2020 09:42:59 -0800 (PST) Message-ID: <5e5d45a3.1c69fb81.f99ac.0806@mx.google.com> From: christian@brauner.io Date: Mon, 02 Mar 2020 18:42:57 +0100 User-Agent: K-9 Mail for Android In-Reply-To: References: <20200301185244.zkofjus6xtgkx4s3@wittgenstein> <87a74zmfc9.fsf@x220.int.ebiederm.org> <87k142lpfz.fsf@x220.int.ebiederm.org> <875zfmloir.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCHv2] exec: Fix a deadlock in ptrace To: Jann Horn , Bernd Edlinger CC: "Eric W. Biederman" , James Morris , Jonathan Corbet , Alexander Viro , Andrew Morton , Alexey Dobriyan , Thomas Gleixner , Oleg Nesterov , Frederic Weisbecker , Andrei Vagin , Ingo Molnar , "Peter Zijlstra (Intel)" , Yuyang Du , David Hildenbrand , Sebastian Andrzej Siewior , Anshuman Khandual , David Howells , Kees Cook , Greg Kroah-Hartman , Shakeel Butt , Jason Gunthorpe , Christian Kellner , Andrea Arcangeli , Aleksa Sarai , "Dmitry V. Levin" , linux-doc@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ,"linux-kernel@vger.kernel.org" ,"linux-fsdevel@vger.kernel.org" ,"linux-mm@kvack.org" ,"stable@vger.kernel.org" ,linux-security-module From: Christian Brauner Message-ID: <9C3BF644-0F82-48C9-9116-8554204FB57D@ubuntu.com> On March 2, 2020 6:37:27 PM GMT+01:00, Jann Horn wrote= : >On Mon, Mar 2, 2020 at 6:01 PM Bernd Edlinger > wrote: >> On 3/2/20 5:43 PM, Jann Horn wrote: >> > On Mon, Mar 2, 2020 at 5:19 PM Eric W=2E Biederman > wrote: >> >> >> >> Bernd Edlinger writes: >> >> >> >>> On 3/2/20 4:57 PM, Eric W=2E Biederman wrote: >> >>>> Bernd Edlinger writes: >> >>>> >> >>>>> >> >>>>> I tried this with s/EACCESS/EACCES/=2E >> >>>>> >> >>>>> The test case in this patch is not fixed, but strace does not >freeze, >> >>>>> at least with my setup where it did freeze repeatable=2E >> >>>> >> >>>> Thanks, That is what I was aiming at=2E >> >>>> >> >>>> So we have one method we can pursue to fix this in practice=2E >> >>>> >> >>>>> That is >> >>>>> obviously because it bypasses the cred_guard_mutex=2E But all >other >> >>>>> process that access this file still freeze, and cannot be >> >>>>> interrupted except with kill -9=2E >> >>>>> >> >>>>> However that smells like a denial of service, that this >> >>>>> simple test case which can be executed by guest, creates a >/proc/$pid/mem >> >>>>> that freezes any process, even root, when it looks at it=2E >> >>>>> I mean: "ln -s README /proc/$pid/mem" would be a nice bomb=2E >> >>>> >> >>>> Yes=2E Your the test case in your patch a variant of the original >> >>>> problem=2E >> >>>> >> >>>> >> >>>> I have been staring at this trying to understand the >fundamentals of the >> >>>> original deeper problem=2E >> >>>> >> >>>> The current scope of cred_guard_mutex in exec is because being >ptraced >> >>>> causes suid exec to act differently=2E So we need to know early >if we are >> >>>> ptraced=2E >> >>>> >> >>> >> >>> It has a second use, that it prevents two threads entering >execve, >> >>> which would probably result in disaster=2E >> >> >> >> Exec can fail with an error code up until de_thread=2E de_thread >causes >> >> exec to fail with the error code -EAGAIN for the second thread to >get >> >> into de_thread=2E >> >> >> >> So no=2E The cred_guard_mutex is not needed for that case at all=2E >> >> >> >>>> If that case did not exist we could reduce the scope of the >> >>>> cred_guard_mutex in exec to where your patch puts the >cred_change_mutex=2E >> >>>> >> >>>> I am starting to think reworking how we deal with ptrace and >exec is the >> >>>> way to solve this problem=2E >> >> >> >> >> >> I am 99% convinced that the fix is to move cred_guard_mutex down=2E >> > >> > "move cred_guard_mutex down" as in "take it once we've already set >up >> > the new process, past the point of no return"? >> > >> >> Then right after we take cred_guard_mutex do: >> >> if (ptraced) { >> >> use_original_creds(); >> >> } >> >> >> >> And call it a day=2E >> >> >> >> The details suck but I am 99% certain that would solve everyones >> >> problems, and not be too bad to audit either=2E >> > >> > Ah, hmm, that sounds like it'll work fine at least when no LSMs are >involved=2E >> > >> > SELinux normally doesn't do the execution-degrading thing, it just >> > blocks the execution completely - see their >selinux_bprm_set_creds() >> > hook=2E So I think they'd still need to set some state on the task >that >> > says "we're currently in the middle of an execution where the >target >> > task will run in context X", and then check against that in the >> > ptrace_may_access hook=2E Or I suppose they could just kill the task >> > near the end of execve, although that'd be kinda ugly=2E >> > >> >> We have current->in_execve for that, right? >> I think when the cred_guard_mutex is taken only in the critical >section, >> then PTRACE_ATTACH could take the guard_mutex, and look at >current->in_execve, >> and just return -EAGAIN in that case, right, everybody happy :) > >It's probably going to mean that things like strace will just randomly >fail to attach to processes if they happen to be in the middle of >execve=2E=2E=2E but I guess that works? That sounds like an acceptable outcome=2E We can at least risk it and if we regress revert or come up with the more complex solution suggested in another mail here?