Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp4408840imm; Mon, 15 Oct 2018 14:25:09 -0700 (PDT) X-Google-Smtp-Source: ACcGV61sLxziSLi1BujGHWAIJ9HyakG1ej2TrMvh+AXbXsSFMkYVaDYEScY3JqO5GMilxvwbOcqR X-Received: by 2002:a65:5c81:: with SMTP id a1-v6mr17491994pgt.390.1539638709632; Mon, 15 Oct 2018 14:25:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539638709; cv=none; d=google.com; s=arc-20160816; b=da9gvewBCc/tZfC/FHGxxUQKUBaUTRrJ8ighcCS+mYgAFZyyOYNfEZEIJiWSeR8LJo KX5Ta3mGxlt/tZEGyD5nVPhtvQdu8x7Om1YgUcVysv9Ul8BOaA0HXEqo9cVd3aFttT98 bU/UNByQw9rayjrZOzpf+IKosMiW1JWVGXlPGllgRiFqgNp3szNrqNEQ0QTwRuBi98+Y +uTjaMdnihOZGl9RvDF6CpXjxfJ2IXEBiWBp/oHU1+lHRb7+OGbw/V0KVlpE7x/NdkWZ DAQ66lrbLssXSCkjZEXow/9r4EfNFPw2zL9Y9zY2Y5eVp6CScmcA7+SCv/NedOjdORl9 nuVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=4SkfwOav5hqDUEDwMO/dmvbeZDxLyJ7CHiqH/HfRIu0=; b=gniZOkYk4On+wEuvgdgej7mgKQ9fPgoGvnnrSDj3SOwdxFKx+7Ay/YRE6rybwFXWfR 9hlfKdzuW++jbwpZReKRnrL1yz+JxXUiOoVgzfl6jcqsRMvMOSC65FW1O3dt70MabpCH qZXFbr3bXV4gx1UmMzSjFVKgrEa9xJgPA1HdWKQWTmZUGRfXn5WCyc4bftATlL8+3nPi iwWhwmCjnTM6lVyoFij3EIatEXzE6dgD6fPuQ3J204Stos77uQ3Y7Jjq3eUpFDc7p5Qy 07AXEd0fmGUIB+codwDsOoty7OBM25INs6umn5WnNcWtkBxDXT0cp+QajIOgjZdLtGVY GNaA== ARC-Authentication-Results: i=1; mx.google.com; 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 c31-v6si11944687pgl.166.2018.10.15.14.24.53; Mon, 15 Oct 2018 14:25:09 -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; 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 S1726936AbeJPFKM (ORCPT + 99 others); Tue, 16 Oct 2018 01:10:12 -0400 Received: from www.llwyncelyn.cymru ([82.70.14.225]:35432 "EHLO fuzix.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725974AbeJPFKM (ORCPT ); Tue, 16 Oct 2018 01:10:12 -0400 Received: from alans-desktop (82-70-14-226.dsl.in-addr.zen.co.uk [82.70.14.226]) by fuzix.org (8.15.2/8.15.2) with ESMTP id w9FLLiqJ025498; Mon, 15 Oct 2018 22:21:45 +0100 Date: Mon, 15 Oct 2018 22:21:44 +0100 From: Alan Cox To: Enke Chen Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , x86@kernel.org, Peter Zijlstra , Arnd Bergmann , "Eric W. Biederman" , Khalid Aziz , Kate Stewart , Helge Deller , Greg Kroah-Hartman , Al Viro , Andrew Morton , Christian Brauner , Catalin Marinas , Will Deacon , Dave Martin , Mauro Carvalho Chehab , Michal Hocko , Rik van Riel , "Kirill A. Shutemov" , Roman Gushchin , Marcos Paulo de Souza , Oleg Nesterov , Dominik Brodowski , Cyrill Gorcunov , Yang Shi , Jann Horn , Kees Cook , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, "Victor Kamensky (kamensky)" , xe-linux-external@cisco.com, Stefan Strogin Subject: Re: [PATCH] kernel/signal: Signal-based pre-coredump notification Message-ID: <20181015222144.27fdafc3@alans-desktop> In-Reply-To: References: Organization: Intel Corporation X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > +/* > + * Returns true if current's euid is same as p's uid or euid, > + * or has CAP_SYS_ADMIN. > + * > + * Called with rcu_read_lock, creds are safe. > + * > + * Adapted from set_one_prio_perm(). > + */ > +static bool set_predump_signal_perm(struct task_struct *p) > +{ > + const struct cred *cred = current_cred(), *pcred = __task_cred(p); > + > + return uid_eq(pcred->uid, cred->euid) || > + uid_eq(pcred->euid, cred->euid) || > + capable(CAP_SYS_ADMIN); > +} This makes absolutely no security sense whatsoever. The uid and euid of the parent and child can both change between the test and the signal delivery. There are reasons that the child signal control code is incredibly careful about either the parent or child using execve or doing a privilege change that might pose a risk. Until this code gets the same protections I don't believe it's safe. Alan