From patchwork Thu May 28 15:44:00 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Eric W. Biederman" X-Patchwork-Id: 11576229 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 05FD11391 for ; Thu, 28 May 2020 15:48:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E1892207F5 for ; Thu, 28 May 2020 15:48:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404741AbgE1Prz (ORCPT ); Thu, 28 May 2020 11:47:55 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:50942 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404544AbgE1Pry (ORCPT ); Thu, 28 May 2020 11:47:54 -0400 Received: from in01.mta.xmission.com ([166.70.13.51]) by out02.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jeKl6-0004W3-WE; Thu, 28 May 2020 09:47:53 -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 1jeKl5-00075p-Nb; Thu, 28 May 2020 09:47:52 -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:00 -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: <87r1v4xdxb.fsf_-_@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 X-XM-SPF: eid=1jeKl5-00075p-Nb;;;mid=<87r1v4xdxb.fsf_-_@x220.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19VmBdjmZhr7D8UoDa9++wsyncidLVa1jw= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on sa03.xmission.com X-Spam-Level: **** X-Spam-Status: No, score=4.3 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,T_TM2_M_HEADER_IN_MSG,T_TooManySym_01,XMNoVowels, XMSubLong,XMSubMetaSxObfu_03,XMSubMetaSx_00 autolearn=disabled version=3.4.2 X-Spam-Virus: No X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.7 XMSubLong Long Subject * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa03 0; Body=1 Fuz1=1 Fuz2=1] * 1.0 XMSubMetaSx_00 1+ Sexy Words * 1.2 XMSubMetaSxObfu_03 Obfuscated Sexy Noun-People * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: ; sa03 0; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ****; X-Spam-Relay-Country: X-Spam-Timing: total 846 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 4.3 (0.5%), b_tie_ro: 3.0 (0.4%), parse: 1.16 (0.1%), extract_message_metadata: 11 (1.2%), get_uri_detail_list: 2.5 (0.3%), tests_pri_-1000: 11 (1.3%), tests_pri_-950: 1.03 (0.1%), tests_pri_-900: 0.86 (0.1%), tests_pri_-90: 365 (43.2%), check_bayes: 363 (43.0%), b_tokenize: 11 (1.3%), b_tok_get_all: 185 (21.9%), b_comp_prob: 3.1 (0.4%), b_tok_touch_all: 161 (19.0%), b_finish: 0.77 (0.1%), tests_pri_0: 441 (52.2%), check_dkim_signature: 0.46 (0.1%), check_dkim_adsp: 2.4 (0.3%), poll_dns_idle: 0.89 (0.1%), tests_pri_10: 1.78 (0.2%), tests_pri_500: 6 (0.7%), rewrite_mail: 0.00 (0.0%) Subject: [PATCH 04/11] exec: Move uid/gid handling from creds_from_file into bprm_fill_uid X-Spam-Flag: No 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-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org The logic in cap_bprm_creds_from_file is difficult to follow in part because it handles both uids/gids and capabilities. That difficulty in following the code has resulted in several small bugs. Move the handling of uids/gids into bprm_fill_uid to make the code clearer. A small bug is fixed where the ambient capabilities were unnecessarily cleared when the presence of a ptracer or a shared fs_struct resulted in the setuid or setgid not being honored. This bug was not possible to leave in place with the movement of the uids and gids handling out of cap_bprm_repopultate_creds. The rest of the bugs I have tried to make more apparent but left in tact when moving the code into bprm_fill_uid. Ref: ee67ae7ef6ff ("commoncap: Move cap_elevated calculation into bprm_set_creds") Fixes: 58319057b784 ("capabilities: ambient capabilities") Signed-off-by: "Eric W. Biederman" --- fs/exec.c | 49 ++++++++++++++++++++++++++++++++++++-------- security/commoncap.c | 25 +++++++--------------- 2 files changed, 48 insertions(+), 26 deletions(-) diff --git a/fs/exec.c b/fs/exec.c index 091ff6269610..956ee3a0d824 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1590,21 +1590,23 @@ static void check_unsafe_exec(struct linux_binprm *bprm) static void bprm_fill_uid(struct linux_binprm *bprm) { /* Handle suid and sgid on files */ + struct cred *new = bprm->cred; struct inode *inode; unsigned int mode; + bool need_cap; kuid_t uid; kgid_t gid; if (!mnt_may_suid(bprm->file->f_path.mnt)) - return; + goto after_setid; if (task_no_new_privs(current)) - return; + goto after_setid; inode = bprm->file->f_path.dentry->d_inode; mode = READ_ONCE(inode->i_mode); if (!(mode & (S_ISUID|S_ISGID))) - return; + goto after_setid; /* Be careful if suid/sgid is set */ inode_lock(inode); @@ -1616,19 +1618,50 @@ static void bprm_fill_uid(struct linux_binprm *bprm) inode_unlock(inode); /* We ignore suid/sgid if there are no mappings for them in the ns */ - if (!kuid_has_mapping(bprm->cred->user_ns, uid) || - !kgid_has_mapping(bprm->cred->user_ns, gid)) - return; + if (!kuid_has_mapping(new->user_ns, uid) || + !kgid_has_mapping(new->user_ns, gid)) + goto after_setid; if (mode & S_ISUID) { bprm->per_clear = 1; - bprm->cred->euid = uid; + new->euid = uid; } if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) { bprm->per_clear = 1; - bprm->cred->egid = gid; + new->egid = gid; + } + +after_setid: + /* Will the new creds have multiple uids or gids? */ + if (!uid_eq(new->euid, new->uid) || !gid_eq(new->egid, new->gid)) { + bprm->secureexec = 1; + + /* + * Is the root directory and working directory shared or is + * the process traced and the tracing process does not have + * CAP_SYS_PTRACE? + * + * In either case it is not safe to change the euid or egid + * unless the current process has the appropriate cap and so + * chaning the euid or egid was already possible. + */ + need_cap = bprm->unsafe & LSM_UNSAFE_SHARE || + !ptracer_capable(current, new->user_ns); + if (need_cap && !uid_eq(new->euid, new->uid) && + (!ns_capable(new->user_ns, CAP_SETUID) || + (bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS))) { + new->euid = new->uid; + } + if (need_cap && !gid_eq(new->egid, new->gid) && + (!ns_capable(new->user_ns, CAP_SETUID) || + (bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS))) { + new->egid = new->gid; + } } + + new->suid = new->fsuid = new->euid; + new->sgid = new->fsgid = new->egid; } /* diff --git a/security/commoncap.c b/security/commoncap.c index 2bd1f24f3796..b39c7511862e 100644 --- a/security/commoncap.c +++ b/security/commoncap.c @@ -809,7 +809,7 @@ int cap_bprm_creds_from_file(struct linux_binprm *bprm) /* Process setpcap binaries and capabilities for uid 0 */ const struct cred *old = current_cred(); struct cred *new = bprm->cred; - bool effective = false, has_fcap = false, is_setid; + bool effective = false, has_fcap = false; int ret; kuid_t root_uid; @@ -828,31 +828,21 @@ int cap_bprm_creds_from_file(struct linux_binprm *bprm) if (__cap_gained(permitted, new, old)) bprm->per_clear = 1; - /* Don't let someone trace a set[ug]id/setpcap binary with the revised + /* Don't let someone trace a setpcap binary with the revised * credentials unless they have the appropriate permit. * * In addition, if NO_NEW_PRIVS, then ensure we get no new privs. */ - is_setid = __is_setuid(new, old) || __is_setgid(new, old); - - if ((is_setid || __cap_gained(permitted, new, old)) && + if (__cap_gained(permitted, new, old) && ((bprm->unsafe & ~LSM_UNSAFE_PTRACE) || !ptracer_capable(current, new->user_ns))) { /* downgrade; they get no more than they had, and maybe less */ - if (!ns_capable(new->user_ns, CAP_SETUID) || - (bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS)) { - new->euid = new->uid; - new->egid = new->gid; - } new->cap_permitted = cap_intersect(new->cap_permitted, old->cap_permitted); } - new->suid = new->fsuid = new->euid; - new->sgid = new->fsgid = new->egid; - /* File caps or setid cancels ambient. */ - if (has_fcap || is_setid) + if (has_fcap || __is_setuid(new, old) || __is_setgid(new, old)) cap_clear(new->cap_ambient); /* @@ -885,10 +875,9 @@ int cap_bprm_creds_from_file(struct linux_binprm *bprm) return -EPERM; /* Check for privilege-elevated exec. */ - if (is_setid || - (!__is_real(root_uid, new) && - (effective || - __cap_grew(permitted, ambient, new)))) + if (!__is_real(root_uid, new) && + (effective || + __cap_grew(permitted, ambient, new))) bprm->secureexec = 1; return 0; From patchwork Thu May 28 15:44:35 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Eric W. Biederman" X-Patchwork-Id: 11576233 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id D4E6760D for ; Thu, 28 May 2020 15:48:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C6E8F20897 for ; Thu, 28 May 2020 15:48:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404630AbgE1Psb (ORCPT ); Thu, 28 May 2020 11:48:31 -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 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 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on sa05.xmission.com X-Spam-Level: **** X-Spam-Status: No, score=4.3 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,T_TM2_M_HEADER_IN_MSG,T_TooManySym_01,XMNoVowels, XMSubLong,XMSubMetaSxObfu_03,XMSubMetaSx_00 autolearn=disabled version=3.4.2 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * 0.7 XMSubLong Long Subject * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa05 0; Body=1 Fuz1=1 Fuz2=1] * 1.0 XMSubMetaSx_00 1+ Sexy Words * 1.2 XMSubMetaSxObfu_03 Obfuscated Sexy Noun-People * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: ; sa05 0; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ****; X-Spam-Relay-Country: X-Spam-Timing: total 506 ms - load_scoreonly_sql: 0.10 (0.0%), signal_user_changed: 12 (2.4%), b_tie_ro: 10 (1.9%), parse: 1.84 (0.4%), extract_message_metadata: 24 (4.6%), get_uri_detail_list: 2.0 (0.4%), tests_pri_-1000: 36 (7.1%), tests_pri_-950: 2.4 (0.5%), tests_pri_-900: 1.68 (0.3%), tests_pri_-90: 129 (25.6%), check_bayes: 126 (24.9%), b_tokenize: 25 (4.9%), b_tok_get_all: 12 (2.4%), b_comp_prob: 5 (1.0%), b_tok_touch_all: 77 (15.1%), b_finish: 2.6 (0.5%), tests_pri_0: 278 (55.0%), check_dkim_signature: 1.08 (0.2%), check_dkim_adsp: 4.3 (0.9%), poll_dns_idle: 0.56 (0.1%), tests_pri_10: 2.1 (0.4%), tests_pri_500: 12 (2.4%), rewrite_mail: 0.00 (0.0%) Subject: [PATCH 05/11] exec: In bprm_fill_uid use CAP_SETGID to see if a gid change is safe X-Spam-Flag: No 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-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@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; } From patchwork Thu May 28 15:48:11 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Eric W. Biederman" X-Patchwork-Id: 11576235 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id B742A1391 for ; Thu, 28 May 2020 15:52:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A9EAF207F9 for ; Thu, 28 May 2020 15:52:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404622AbgE1PwL (ORCPT ); Thu, 28 May 2020 11:52:11 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:49102 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404518AbgE1PwK (ORCPT ); Thu, 28 May 2020 11:52:10 -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 1jeKpA-0004Mo-Cr; Thu, 28 May 2020 09:52:04 -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 1jeKp9-0007rJ-31; Thu, 28 May 2020 09:52:04 -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:48:11 -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: <87ftbkxdqc.fsf_-_@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 X-XM-SPF: eid=1jeKp9-0007rJ-31;;;mid=<87ftbkxdqc.fsf_-_@x220.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19acW7gYINIOd1UYM//vzVBWHHd36D56kw= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on sa01.xmission.com X-Spam-Level: **** X-Spam-Status: No, score=4.3 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,T_TM2_M_HEADER_IN_MSG,T_TooManySym_01,XMNoVowels, XMSubLong,XMSubMetaSxObfu_03,XMSubMetaSx_00 autolearn=disabled version=3.4.2 X-Spam-Virus: No X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.7 XMSubLong Long Subject * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa01 0; Body=1 Fuz1=1 Fuz2=1] * 1.0 XMSubMetaSx_00 1+ Sexy Words * 1.2 XMSubMetaSxObfu_03 Obfuscated Sexy Noun-People * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: ; sa01 0; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ****; X-Spam-Relay-Country: X-Spam-Timing: total 479 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 3.8 (0.8%), b_tie_ro: 2.6 (0.5%), parse: 0.77 (0.2%), extract_message_metadata: 9 (1.9%), get_uri_detail_list: 1.42 (0.3%), tests_pri_-1000: 11 (2.3%), tests_pri_-950: 1.00 (0.2%), tests_pri_-900: 0.81 (0.2%), tests_pri_-90: 119 (24.8%), check_bayes: 118 (24.6%), b_tokenize: 8 (1.6%), b_tok_get_all: 7 (1.5%), b_comp_prob: 1.67 (0.3%), b_tok_touch_all: 98 (20.5%), b_finish: 0.67 (0.1%), tests_pri_0: 323 (67.5%), check_dkim_signature: 0.41 (0.1%), check_dkim_adsp: 1.95 (0.4%), poll_dns_idle: 0.60 (0.1%), tests_pri_10: 1.72 (0.4%), tests_pri_500: 6 (1.2%), rewrite_mail: 0.00 (0.0%) Subject: [PATCH 06/11] exec: Don't set secureexec when the uid or gid changes are abandoned X-Spam-Flag: No 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-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org When the is_secureexec test was removed from cap_bprm_set_creds the test was modified so that it based the status of secureexec on a version of the euid and egid before ptrace and shared fs tests possibly reverted them. The effect of which is that secureexec continued to be set when the euid and egid change were abandoned because the executable was being ptraced to secureexec being set in that same situation. As far as I can tell it is just an oversight and very poor quality of implementation to set AT_SECURE when it is not ncessary. So improve the quality of the implementation by only setting secureexec when there will be multiple uids or gids in the final cred structure. Fixes: ee67ae7ef6ff ("commoncap: Move cap_elevated calculation into bprm_set_creds") Signed-off-by: "Eric W. Biederman" --- fs/exec.c | 48 +++++++++++++++++++++--------------------------- 1 file changed, 21 insertions(+), 27 deletions(-) diff --git a/fs/exec.c b/fs/exec.c index bac8db14f30d..123402f218fe 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1622,44 +1622,38 @@ static void bprm_fill_uid(struct linux_binprm *bprm) !kgid_has_mapping(new->user_ns, gid)) goto after_setid; + /* + * Is the root directory and working directory shared or is + * the process traced and the tracing process does not have + * CAP_SYS_PTRACE? + * + * In either case it is not safe to change the euid or egid + * unless the current process has the appropriate cap and so + * chaning the euid or egid was already possible. + */ + need_cap = bprm->unsafe & LSM_UNSAFE_SHARE || + !ptracer_capable(current, new->user_ns); + if (mode & S_ISUID) { bprm->per_clear = 1; - new->euid = uid; + if (!need_cap || + (ns_capable(new->user_ns, CAP_SETUID) && + !(bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS))) + new->euid = uid; } - if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) { bprm->per_clear = 1; - new->egid = gid; + if (!need_cap || + (ns_capable(new->user_ns, CAP_SETGID) && + !(bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS))) + new->egid = gid; } after_setid: /* Will the new creds have multiple uids or gids? */ - if (!uid_eq(new->euid, new->uid) || !gid_eq(new->egid, new->gid)) { + if (!uid_eq(new->euid, new->uid) || !gid_eq(new->egid, new->gid)) bprm->secureexec = 1; - /* - * Is the root directory and working directory shared or is - * the process traced and the tracing process does not have - * CAP_SYS_PTRACE? - * - * In either case it is not safe to change the euid or egid - * unless the current process has the appropriate cap and so - * chaning the euid or egid was already possible. - */ - need_cap = bprm->unsafe & LSM_UNSAFE_SHARE || - !ptracer_capable(current, new->user_ns); - if (need_cap && !uid_eq(new->euid, new->uid) && - (!ns_capable(new->user_ns, CAP_SETUID) || - (bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS))) { - new->euid = new->uid; - } - if (need_cap && !gid_eq(new->egid, new->gid) && - (!ns_capable(new->user_ns, CAP_SETGID) || - (bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS))) { - new->egid = new->gid; - } - } - new->suid = new->fsuid = new->euid; new->sgid = new->fsgid = new->egid; } From patchwork Thu May 28 15:48:44 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Eric W. Biederman" X-Patchwork-Id: 11576241 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 060411391 for ; Thu, 28 May 2020 15:52:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EAF3B20814 for ; Thu, 28 May 2020 15:52:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404636AbgE1Pwi (ORCPT ); Thu, 28 May 2020 11:52:38 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:52566 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404565AbgE1Pwi (ORCPT ); Thu, 28 May 2020 11:52:38 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]) by out02.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jeKpg-0005EG-KT; Thu, 28 May 2020 09:52:36 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1jeKpf-00033R-Pz; Thu, 28 May 2020 09:52:36 -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:48:44 -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: <87a71sxdpf.fsf_-_@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 X-XM-SPF: eid=1jeKpf-00033R-Pz;;;mid=<87a71sxdpf.fsf_-_@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19L2GQX5s9eCjNWe4gHmrLWVMHrvsxnIhk= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on sa04.xmission.com X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,T_TooManySym_01,T_TooManySym_02,XMNoVowels, XMSubLong autolearn=disabled version=3.4.2 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * 0.7 XMSubLong Long Subject * 1.5 XMNoVowels Alpha-numberic number with no vowels * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa04 0; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_02 5+ unique symbols in subject * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: ; sa04 0; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **; X-Spam-Relay-Country: X-Spam-Timing: total 387 ms - load_scoreonly_sql: 0.07 (0.0%), signal_user_changed: 14 (3.5%), b_tie_ro: 12 (3.0%), parse: 1.36 (0.4%), extract_message_metadata: 16 (4.1%), get_uri_detail_list: 1.55 (0.4%), tests_pri_-1000: 19 (4.8%), tests_pri_-950: 1.59 (0.4%), tests_pri_-900: 1.32 (0.3%), tests_pri_-90: 120 (31.0%), check_bayes: 118 (30.6%), b_tokenize: 9 (2.3%), b_tok_get_all: 7 (1.7%), b_comp_prob: 2.2 (0.6%), b_tok_touch_all: 97 (25.1%), b_finish: 0.87 (0.2%), tests_pri_0: 200 (51.8%), check_dkim_signature: 0.52 (0.1%), check_dkim_adsp: 2.2 (0.6%), poll_dns_idle: 0.55 (0.1%), tests_pri_10: 2.1 (0.5%), tests_pri_500: 8 (2.0%), rewrite_mail: 0.00 (0.0%) Subject: [PATCH 07/11] exec: Set saved, fs, and effective ids together in bprm_fill_uid X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org Now that there is only one place in bprm_fill_uid where the euid and the egid are set, move setting of the saved, and the fs ids to that place. This makes it clear that this is the only location in the function that changes these ids. Signed-off-by: "Eric W. Biederman" --- fs/exec.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/fs/exec.c b/fs/exec.c index 123402f218fe..8dd7254931dc 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1639,23 +1639,20 @@ static void bprm_fill_uid(struct linux_binprm *bprm) if (!need_cap || (ns_capable(new->user_ns, CAP_SETUID) && !(bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS))) - new->euid = uid; + new->suid = new->fsuid = new->euid = uid; } if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) { bprm->per_clear = 1; if (!need_cap || (ns_capable(new->user_ns, CAP_SETGID) && !(bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS))) - new->egid = gid; + new->sgid = new->fsgid = new->egid = gid; } after_setid: /* Will the new creds have multiple uids or gids? */ if (!uid_eq(new->euid, new->uid) || !gid_eq(new->egid, new->gid)) bprm->secureexec = 1; - - new->suid = new->fsuid = new->euid; - new->sgid = new->fsgid = new->egid; } /* From patchwork Thu May 28 15:49:10 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Eric W. Biederman" X-Patchwork-Id: 11576245 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 20AE11391 for ; Thu, 28 May 2020 15:53:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 128712071A for ; Thu, 28 May 2020 15:53:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404667AbgE1PxL (ORCPT ); Thu, 28 May 2020 11:53:11 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:33262 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404565AbgE1PxJ (ORCPT ); Thu, 28 May 2020 11:53:09 -0400 Received: from in01.mta.xmission.com ([166.70.13.51]) by out01.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jeKqC-0001W7-C9; Thu, 28 May 2020 09:53:08 -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 1jeKq6-0007zz-5k; Thu, 28 May 2020 09:53:07 -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:49:10 -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: <874ks0xdop.fsf_-_@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 X-XM-SPF: eid=1jeKq6-0007zz-5k;;;mid=<874ks0xdop.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/ELoUISo4voXjVc4cOnoi5+XqInd2HxUI= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on sa01.xmission.com X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,T_TooManySym_01,XMNoVowels,XMSubLong autolearn=disabled version=3.4.2 X-Spam-Virus: No X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.7 XMSubLong Long Subject * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa01 0; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: ; sa01 0; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **; X-Spam-Relay-Country: X-Spam-Timing: total 515 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 3.5 (0.7%), b_tie_ro: 2.3 (0.4%), parse: 1.20 (0.2%), extract_message_metadata: 15 (2.9%), get_uri_detail_list: 1.48 (0.3%), tests_pri_-1000: 17 (3.3%), tests_pri_-950: 1.47 (0.3%), tests_pri_-900: 1.21 (0.2%), tests_pri_-90: 134 (26.0%), check_bayes: 132 (25.7%), b_tokenize: 10 (1.8%), b_tok_get_all: 7 (1.3%), b_comp_prob: 2.2 (0.4%), b_tok_touch_all: 111 (21.5%), b_finish: 0.71 (0.1%), tests_pri_0: 328 (63.6%), check_dkim_signature: 0.40 (0.1%), check_dkim_adsp: 2.5 (0.5%), poll_dns_idle: 0.81 (0.2%), tests_pri_10: 2.6 (0.5%), tests_pri_500: 8 (1.5%), rewrite_mail: 0.00 (0.0%) Subject: [PATCH 08/11] exec: In bprm_fill_uid remove unnecessary no new privs check X-Spam-Flag: No 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-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org When the no new privs code was added[1], a test was added to cap_bprm_set_creds to ensure that the credential change were always reverted if no new privs was set. That test has been refactored into a test to not make the credential change in bprm_fill_uid when no new privs is set. Remove that unncessary test as it can now been seen by a quick inspection that execution can never make it to the test with no new privs set. The same change[1] also added a test that guaranteed the credentials would never change when no_new_privs was set, so the test I am removing was never necessary but historically that was far from obvious. [1]: 259e5e6c75a9 ("Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs") Signed-off-by: "Eric W. Biederman" --- fs/exec.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/fs/exec.c b/fs/exec.c index 8dd7254931dc..af108ecf9632 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1636,16 +1636,12 @@ static void bprm_fill_uid(struct linux_binprm *bprm) if (mode & S_ISUID) { bprm->per_clear = 1; - if (!need_cap || - (ns_capable(new->user_ns, CAP_SETUID) && - !(bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS))) + if (!need_cap || ns_capable(new->user_ns, CAP_SETUID)) new->suid = new->fsuid = new->euid = uid; } if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) { bprm->per_clear = 1; - if (!need_cap || - (ns_capable(new->user_ns, CAP_SETGID) && - !(bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS))) + if (!need_cap || ns_capable(new->user_ns, CAP_SETGID)) new->sgid = new->fsgid = new->egid = gid; } From patchwork Thu May 28 15:49:44 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Eric W. Biederman" X-Patchwork-Id: 11576247 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id CE50B1391 for ; Thu, 28 May 2020 15:53:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BF470207D3 for ; Thu, 28 May 2020 15:53:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404691AbgE1Pxj (ORCPT ); Thu, 28 May 2020 11:53:39 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:33472 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404511AbgE1Pxh (ORCPT ); Thu, 28 May 2020 11:53:37 -0400 Received: from in01.mta.xmission.com ([166.70.13.51]) by out01.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jeKqe-0001Zi-I4; Thu, 28 May 2020 09:53:36 -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 1jeKqd-00085a-M7; Thu, 28 May 2020 09:53:36 -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:49:44 -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: <87y2pcvz3b.fsf_-_@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 X-XM-SPF: eid=1jeKqd-00085a-M7;;;mid=<87y2pcvz3b.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+Uao3hKNmbCnTKyFSqtDONOkhIC5W+4JQ= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on sa06.xmission.com X-Spam-Level: **** X-Spam-Status: No, score=4.3 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,T_TooManySym_01,XMNoVowels,XMSubLong, XMSubMetaSxObfu_03,XMSubMetaSx_00 autolearn=disabled version=3.4.2 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.7 XMSubLong Long Subject * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa06 0; Body=1 Fuz1=1 Fuz2=1] * 1.0 XMSubMetaSx_00 1+ Sexy Words * 0.0 T_TooManySym_01 4+ unique symbols in subject * 1.2 XMSubMetaSxObfu_03 Obfuscated Sexy Noun-People X-Spam-DCC: ; sa06 0; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ****; X-Spam-Relay-Country: X-Spam-Timing: total 385 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 10 (2.6%), b_tie_ro: 9 (2.3%), parse: 1.04 (0.3%), extract_message_metadata: 11 (2.8%), get_uri_detail_list: 1.44 (0.4%), tests_pri_-1000: 13 (3.4%), tests_pri_-950: 1.24 (0.3%), tests_pri_-900: 1.00 (0.3%), tests_pri_-90: 84 (21.9%), check_bayes: 83 (21.5%), b_tokenize: 8 (2.1%), b_tok_get_all: 8 (2.1%), b_comp_prob: 2.7 (0.7%), b_tok_touch_all: 60 (15.6%), b_finish: 0.94 (0.2%), tests_pri_0: 246 (64.0%), check_dkim_signature: 0.55 (0.1%), check_dkim_adsp: 2.5 (0.6%), poll_dns_idle: 0.48 (0.1%), tests_pri_10: 2.3 (0.6%), tests_pri_500: 12 (3.0%), rewrite_mail: 0.00 (0.0%) Subject: [PATCH 09/11] exec: In bprm_fill_uid only set per_clear when honoring suid or sgid X-Spam-Flag: No 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-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org It makes no sense to set active_per_clear when the kernel decides not to honor the executables setuid or or setgid bits. Instead set active_per_clear when the kernel actually decides to honor the suid or sgid permission bits of an executable. As far as I can tell this was the intended behavior but with the ptrace logic hiding out in security/commcap.c:cap_bprm_apply_creds I believe it was just overlooked that the setuid or setgid operation could be cancelled. History Tree: git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git Fixes: 1bb0fa189c6a ("[PATCH] NX: clean up legacy binary support") Signed-off-by: "Eric W. Biederman" --- fs/exec.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/fs/exec.c b/fs/exec.c index af108ecf9632..347dade4bc54 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1634,15 +1634,16 @@ static void bprm_fill_uid(struct linux_binprm *bprm) need_cap = bprm->unsafe & LSM_UNSAFE_SHARE || !ptracer_capable(current, new->user_ns); - if (mode & S_ISUID) { + if ((mode & S_ISUID) && + (!need_cap || ns_capable(new->user_ns, CAP_SETUID))) { bprm->per_clear = 1; - if (!need_cap || ns_capable(new->user_ns, CAP_SETUID)) - new->suid = new->fsuid = new->euid = uid; + new->suid = new->fsuid = new->euid = uid; } - if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) { + + if (((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) && + (!need_cap || ns_capable(new->user_ns, CAP_SETGID))) { bprm->per_clear = 1; - if (!need_cap || ns_capable(new->user_ns, CAP_SETGID)) - new->sgid = new->fsgid = new->egid = gid; + new->sgid = new->fsgid = new->egid = gid; } after_setid: From patchwork Thu May 28 15:50:09 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Eric W. Biederman" X-Patchwork-Id: 11576253 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 0B08313B4 for ; Thu, 28 May 2020 15:54:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F0CF82053B for ; Thu, 28 May 2020 15:54:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404749AbgE1PyI (ORCPT ); Thu, 28 May 2020 11:54:08 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:53032 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404511AbgE1PyD (ORCPT ); Thu, 28 May 2020 11:54:03 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]) by out02.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jeKr3-0005Lz-CC; Thu, 28 May 2020 09:54:01 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1jeKr2-0003Dg-EH; Thu, 28 May 2020 09:54:01 -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:50:09 -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: <87sgfkvz2m.fsf_-_@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 X-XM-SPF: eid=1jeKr2-0003Dg-EH;;;mid=<87sgfkvz2m.fsf_-_@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+noWZXFqvq+oA4X8eGsRDwP21udiMjpIw= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on sa02.xmission.com X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,T_TooManySym_01,XMNoVowels,XMSubLong autolearn=disabled version=3.4.2 X-Spam-Virus: No X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.7 XMSubLong Long Subject * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa02 0; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: ; sa02 0; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **; X-Spam-Relay-Country: X-Spam-Timing: total 530 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 4.4 (0.8%), b_tie_ro: 3.0 (0.6%), parse: 1.09 (0.2%), extract_message_metadata: 12 (2.2%), get_uri_detail_list: 1.92 (0.4%), tests_pri_-1000: 11 (2.1%), tests_pri_-950: 1.14 (0.2%), tests_pri_-900: 0.85 (0.2%), tests_pri_-90: 229 (43.1%), check_bayes: 227 (42.8%), b_tokenize: 7 (1.3%), b_tok_get_all: 7 (1.2%), b_comp_prob: 1.73 (0.3%), b_tok_touch_all: 209 (39.4%), b_finish: 0.83 (0.2%), tests_pri_0: 262 (49.3%), check_dkim_signature: 0.59 (0.1%), check_dkim_adsp: 2.1 (0.4%), poll_dns_idle: 0.80 (0.2%), tests_pri_10: 1.80 (0.3%), tests_pri_500: 6 (1.0%), rewrite_mail: 0.00 (0.0%) Subject: [PATCH 10/11] exec: In bprm_fill_uid set secureexec at same time as per_clear X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org We currently have two different policies for setting per_clear and for setting secureexec. For per_clear the policy is if the setxid bits on a file are honored. For secureexec the policy is if the resulting credentials will have multiple uids or gids. Looking closely the policy for setting AT_SECURE and asking userspace not to trust our caller in all cases where we have multiple uids or gids does not make sense. In some of those cases it is the caller of exec that provides multiple uids and gids. The point of setting AT_SECURE is so that the called application or it's libraries can take defensive measures to guard against a lesser privileged program which calls it via exec. If all of your privilege comes from your caller there is no point in taking defensive measures, against them. Further the only way that libc or other userspace can know that the privilege came from the caller of exec and not from the exec being suid or sgid is by the kernel telling it. As userspace does not have enough information to distinguish between these two cases. So set secureexec when the exec itself results in multiple uids or gids, not when we happen to have mulitple ids because the binary was called that way. Signed-off-by: "Eric W. Biederman" --- fs/exec.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/exec.c b/fs/exec.c index 347dade4bc54..fc4edc7517a6 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1637,19 +1637,19 @@ static void bprm_fill_uid(struct linux_binprm *bprm) if ((mode & S_ISUID) && (!need_cap || ns_capable(new->user_ns, CAP_SETUID))) { bprm->per_clear = 1; + bprm->secureexec = 1; new->suid = new->fsuid = new->euid = uid; } if (((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) && (!need_cap || ns_capable(new->user_ns, CAP_SETGID))) { bprm->per_clear = 1; + bprm->secureexec = 1; new->sgid = new->fsgid = new->egid = gid; } after_setid: - /* Will the new creds have multiple uids or gids? */ - if (!uid_eq(new->euid, new->uid) || !gid_eq(new->egid, new->gid)) - bprm->secureexec = 1; + ; } /* From patchwork Thu May 28 15:50:36 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Eric W. Biederman" X-Patchwork-Id: 11576257 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 868E913B4 for ; Thu, 28 May 2020 15:54:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7639D2071A for ; Thu, 28 May 2020 15:54:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404597AbgE1Pyg (ORCPT ); Thu, 28 May 2020 11:54:36 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:49760 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404774AbgE1Pyc (ORCPT ); Thu, 28 May 2020 11:54:32 -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 1jeKrU-0004Y0-Lc; Thu, 28 May 2020 09:54:29 -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 1jeKrT-0008Bp-Qq; Thu, 28 May 2020 09:54: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:50:36 -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: <87mu5svz1v.fsf_-_@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 X-XM-SPF: eid=1jeKrT-0008Bp-Qq;;;mid=<87mu5svz1v.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+MHtH6hLkB3oWNuRodn+5tMsim9ktuu6s= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on sa06.xmission.com X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,T_TooManySym_01,XMNoVowels,XMSubLong autolearn=disabled version=3.4.2 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.7 XMSubLong Long Subject * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa06 0; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: ; sa06 0; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **; X-Spam-Relay-Country: X-Spam-Timing: total 408 ms - load_scoreonly_sql: 0.41 (0.1%), signal_user_changed: 14 (3.3%), b_tie_ro: 11 (2.7%), parse: 1.64 (0.4%), extract_message_metadata: 15 (3.6%), get_uri_detail_list: 1.60 (0.4%), tests_pri_-1000: 13 (3.2%), tests_pri_-950: 1.27 (0.3%), tests_pri_-900: 1.05 (0.3%), tests_pri_-90: 134 (32.9%), check_bayes: 132 (32.5%), b_tokenize: 7 (1.8%), b_tok_get_all: 7 (1.8%), b_comp_prob: 1.88 (0.5%), b_tok_touch_all: 113 (27.6%), b_finish: 0.89 (0.2%), tests_pri_0: 214 (52.5%), check_dkim_signature: 0.57 (0.1%), check_dkim_adsp: 2.1 (0.5%), poll_dns_idle: 0.57 (0.1%), tests_pri_10: 2.5 (0.6%), tests_pri_500: 8 (1.9%), rewrite_mail: 0.00 (0.0%) Subject: [PATCH 11/11] exec: Remove the label after_setid from bprm_fill_uid X-Spam-Flag: No 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-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org There is nothing past the label after_setid in bprm_fill_uid so replace code that jumps to it with return, and delete the label entirely. Signed-off-by: "Eric W. Biederman" --- fs/exec.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/fs/exec.c b/fs/exec.c index fc4edc7517a6..ccb552fcdcff 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1598,15 +1598,15 @@ static void bprm_fill_uid(struct linux_binprm *bprm) kgid_t gid; if (!mnt_may_suid(bprm->file->f_path.mnt)) - goto after_setid; + return; if (task_no_new_privs(current)) - goto after_setid; + return; inode = bprm->file->f_path.dentry->d_inode; mode = READ_ONCE(inode->i_mode); if (!(mode & (S_ISUID|S_ISGID))) - goto after_setid; + return; /* Be careful if suid/sgid is set */ inode_lock(inode); @@ -1620,7 +1620,7 @@ static void bprm_fill_uid(struct linux_binprm *bprm) /* We ignore suid/sgid if there are no mappings for them in the ns */ if (!kuid_has_mapping(new->user_ns, uid) || !kgid_has_mapping(new->user_ns, gid)) - goto after_setid; + return; /* * Is the root directory and working directory shared or is @@ -1647,9 +1647,6 @@ static void bprm_fill_uid(struct linux_binprm *bprm) bprm->secureexec = 1; new->sgid = new->fsgid = new->egid = gid; } - -after_setid: - ; } /*