Message ID | 1499673451-66160-5-git-send-email-keescook@chromium.org (mailing list archive) |
---|---|
State | New, archived |
Headers | show
Return-Path: <linux-security-module-owner@kernel.org> Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 471F160318 for <patchwork-linux-security-module@patchwork.kernel.org>; Mon, 10 Jul 2017 08:00:20 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3BC3826E3A for <patchwork-linux-security-module@patchwork.kernel.org>; Mon, 10 Jul 2017 08:00:20 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 2FDB527861; Mon, 10 Jul 2017 08:00:20 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 25FAD26E3A for <patchwork-linux-security-module@patchwork.kernel.org>; Mon, 10 Jul 2017 08:00:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753521AbdGJIAF (ORCPT <rfc822;patchwork-linux-security-module@patchwork.kernel.org>); Mon, 10 Jul 2017 04:00:05 -0400 Received: from mail-pf0-f169.google.com ([209.85.192.169]:36600 "EHLO mail-pf0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753564AbdGJH5m (ORCPT <rfc822;linux-security-module@vger.kernel.org>); Mon, 10 Jul 2017 03:57:42 -0400 Received: by mail-pf0-f169.google.com with SMTP id q86so45938760pfl.3 for <linux-security-module@vger.kernel.org>; Mon, 10 Jul 2017 00:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=8WYH5HMDCQFMwTgQj611A5NWf5KKrPedGh1Kq77m/2Q=; b=eDrVz8G8/e+TKzECljrYIHId+fB0BxMDXDzVmdO7dD28PDlUD8kZmI1Kg508FarEto yEFOhm4Bnv9Tin1nPHm3JNf+FPzmnT4+3DDZuT8Att8+tdMw+Kw1Ud5gmGB6Q6LCLnSr lMdlsVVYidUErysb3Zrw80HN/juayek3ErvKY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=8WYH5HMDCQFMwTgQj611A5NWf5KKrPedGh1Kq77m/2Q=; b=Eex30JzqbBcvHBW1RXVj2kEqFreXCmv5sjamXDHfGRewj7HQLLgYd/2zLJv6LIdk7t GnzYpQXhz6mTm+/zC87Q+uDXTOZ8ZAPRuE5E8D1QBhvgJPK/17Vpt2rZrhvjIgbiyxBs XBSCF9TTtOPhAJuz4bbWJv9c14sUiwSfMFve/Wt+CtSir0lMU5w1mrCXvWzaYd1P+6Sa Em9xwsraNfKGCoMwuBZnyZjMcqzbzCQ5IkM/B9FP3OcHtF918aSBBF5ofjG+jZIv1QOq DLveRfaTKU1vUnuvw3aLw8wcVl0FJ+6pugaOHwXalNsrloGdAoxfoOMTfIYzgK92Pz6B gb5g== X-Gm-Message-State: AIVw110sk8JkzxneSqgsDWYgP0jFkbONGUXnVLc72pOL7ZqP0s884t/p +eMVjj5N4PEAVf08 X-Received: by 10.84.238.1 with SMTP id u1mr7582264plk.187.1499673461204; Mon, 10 Jul 2017 00:57:41 -0700 (PDT) Received: from www.outflux.net (173-164-112-133-Oregon.hfc.comcastbusiness.net. [173.164.112.133]) by smtp.gmail.com with ESMTPSA id w125sm9852512pfb.117.2017.07.10.00.57.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jul 2017 00:57:37 -0700 (PDT) From: Kees Cook <keescook@chromium.org> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: Kees Cook <keescook@chromium.org>, Andy Lutomirski <luto@kernel.org>, David Howells <dhowells@redhat.com>, Serge Hallyn <serge@hallyn.com>, John Johansen <john.johansen@canonical.com>, Casey Schaufler <casey@schaufler-ca.com>, "Eric W. Biederman" <ebiederm@xmission.com>, Alexander Viro <viro@zeniv.linux.org.uk>, Michal Hocko <mhocko@kernel.org>, Ben Hutchings <ben@decadent.org.uk>, Hugh Dickins <hughd@google.com>, Oleg Nesterov <oleg@redhat.com>, "Jason A. Donenfeld" <Jason@zx2c4.com>, Rik van Riel <riel@redhat.com>, James Morris <james.l.morris@oracle.com>, Greg Ungerer <gerg@linux-m68k.org>, Ingo Molnar <mingo@kernel.org>, Nicolas Pitre <nicolas.pitre@linaro.org>, Stephen Smalley <sds@tycho.nsa.gov>, Paul Moore <paul@paul-moore.com>, Vivek Goyal <vgoyal@redhat.com>, =?UTF-8?q?Micka=C3=ABl=20Sala=C3=BCn?= <mic@digikod.net>, Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, selinux@tycho.nsa.gov Subject: [PATCH v2 4/8] exec: Use secureexec for clearing pdeath_signal Date: Mon, 10 Jul 2017 00:57:27 -0700 Message-Id: <1499673451-66160-5-git-send-email-keescook@chromium.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1499673451-66160-1-git-send-email-keescook@chromium.org> References: <1499673451-66160-1-git-send-email-keescook@chromium.org> Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: <linux-security-module.vger.kernel.org> X-Virus-Scanned: ClamAV using ClamSMTP |
diff --git a/fs/exec.c b/fs/exec.c index 3e519d4f0bd3..d7bda5b60e7b 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1361,8 +1361,7 @@ void setup_new_exec(struct linux_binprm * bprm) */ current->mm->task_size = TASK_SIZE; - if (!uid_eq(bprm->cred->uid, current_euid()) || - !gid_eq(bprm->cred->gid, current_egid())) { + if (bprm->secureexec) { current->pdeath_signal = 0; } else { if (bprm->interp_flags & BINPRM_FLAGS_ENFORCE_NONDUMP)
Like dumpability, clearing pdeath_signal happens both in setup_new_exec() and later in commit_creds(). The test in setup_new_exec() is different from all other privilege comparisons, though: it is checking the new cred (bprm) uid vs the old cred (current) euid. This appears to be a bug, introduced by commit a6f76f23d297 ("CRED: Make execve() take advantage of copy-on-write credentials"): - if (bprm->e_uid != current_euid() || - bprm->e_gid != current_egid()) { - set_dumpable(current->mm, suid_dumpable); + /* install the new credentials */ + if (bprm->cred->uid != current_euid() || + bprm->cred->gid != current_egid()) { It was bprm euid vs current euid (and egids), but the effective got dropped. Nothing in the exec flow changes bprm->cred->uid (nor gid). The call traces are: prepare_bprm_creds() prepare_exec_creds() prepare_creds() memcpy(new_creds, old_creds, ...) security_prepare_creds() (unimplemented by commoncap) ... prepare_binprm() bprm_fill_uid() resets euid/egid to current euid/egid sets euid/egid on bprm based on set*id file bits security_bprm_set_creds() cap_bprm_set_creds() handle all caps-based manipulations so this test is effectively a test of current_uid() vs current_euid(), which is wrong, just like the prior dumpability tests were wrong. The commit log says "Clear pdeath_signal and set dumpable on certain circumstances that may not be covered by commit_creds()." This may be meaning the earlier old euid vs new euid (and egid) test that got changed. Luckily, as with dumpability, this is all masked by commit_creds() which performs old/new euid and egid tests and clears pdeath_signal. And again, like dumpability, we should include LSM secureexec logic for pdeath_signal clearing. For example, Smack goes out of its way to clear pdeath_signal when it finds a secureexec condition. Signed-off-by: Kees Cook <keescook@chromium.org> --- fs/exec.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)