From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7C4FDC433DF for ; Thu, 28 May 2020 15:48:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 64692207F5 for ; Thu, 28 May 2020 15:48:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404759AbgE1Psg (ORCPT ); Thu, 28 May 2020 11:48:36 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:47924 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404544AbgE1Ps3 (ORCPT ); Thu, 28 May 2020 11:48:29 -0400 Received: from in01.mta.xmission.com ([166.70.13.51]) by out03.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jeKlg-0003vA-65; Thu, 28 May 2020 09:48:28 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1jeKlf-0007Eb-7U; Thu, 28 May 2020 09:48:28 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Cc: Linus Torvalds , Oleg Nesterov , Jann Horn , Kees Cook , Greg Ungerer , Rob Landley , Bernd Edlinger , , Al Viro , Alexey Dobriyan , Andrew Morton , Casey Schaufler , linux-security-module@vger.kernel.org, James Morris , "Serge E. Hallyn" , Andy Lutomirski References: <87h7wujhmz.fsf@x220.int.ebiederm.org> <87sgga6ze4.fsf@x220.int.ebiederm.org> <87v9l4zyla.fsf_-_@x220.int.ebiederm.org> <877dx822er.fsf_-_@x220.int.ebiederm.org> <87k10wysqz.fsf_-_@x220.int.ebiederm.org> Date: Thu, 28 May 2020 10:44:35 -0500 In-Reply-To: <87k10wysqz.fsf_-_@x220.int.ebiederm.org> (Eric W. Biederman's message of "Thu, 28 May 2020 10:38:28 -0500") Message-ID: <87lflcxdwc.fsf_-_@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1jeKlf-0007Eb-7U;;;mid=<87lflcxdwc.fsf_-_@x220.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/QbUmGNs6WJY8er87D7LRHfXhQCTcWzGM= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: [PATCH 05/11] exec: In bprm_fill_uid use CAP_SETGID to see if a gid change is safe X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org If the task has CAP_SETGID and a shared fs struct or is being ptraced than it is clear that nothing new is being introduced when the gid changes, and so it is safe to honor a setgid executable. However if all we know is that the task has CAP_SETUID things are less clear. This bug looks like it was introduced in v2.1.100 when !suser was replaced by !capable(CAP_SETUID). It appears to have been an oversight at that time. Fixing this 22 years later seems weird but even now it still looks worth fixing. As conceptually what is happening is testing to see if the process already had the potential to make a gid change or if the trancer needs permissions in addition to the permissions needed to trace the process to trace the process through a gid change. Fixes: v2.1.100 Signed-off-by: "Eric W. Biederman" --- fs/exec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/exec.c b/fs/exec.c index 956ee3a0d824..bac8db14f30d 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1654,7 +1654,7 @@ static void bprm_fill_uid(struct linux_binprm *bprm) new->euid = new->uid; } if (need_cap && !gid_eq(new->egid, new->gid) && - (!ns_capable(new->user_ns, CAP_SETUID) || + (!ns_capable(new->user_ns, CAP_SETGID) || (bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS))) { new->egid = new->gid; } -- 2.25.0