From: Kees Cook <keescook@chromium.org> To: Andrew Morton <akpm@linux-foundation.org> Cc: Kees Cook <keescook@chromium.org>, David Howells <dhowells@redhat.com>, "Eric W. Biederman" <ebiederm@xmission.com>, John Johansen <john.johansen@canonical.com>, "Serge E. Hallyn" <serge@hallyn.com>, Paul Moore <paul@paul-moore.com>, Stephen Smalley <sds@tycho.nsa.gov>, Casey Schaufler <casey@schaufler-ca.com>, Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>, James Morris <james.l.morris@oracle.com>, Andy Lutomirski <luto@kernel.org>, Linus Torvalds <torvalds@linux-foundation.org>, linux-fsdevel@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v4 11/15] exec: Use secureexec for clearing pdeath_signal Date: Mon, 31 Jul 2017 16:51:29 -0700 [thread overview] Message-ID: <1501545093-56634-12-git-send-email-keescook@chromium.org> (raw) In-Reply-To: <1501545093-56634-1-git-send-email-keescook@chromium.org> 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); + 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. Cc: David Howells <dhowells@redhat.com> Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Serge Hallyn <serge@hallyn.com> --- fs/exec.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/exec.c b/fs/exec.c index f9997ea6414e..708a72f93320 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1348,8 +1348,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) -- 2.7.4
WARNING: multiple messages have this Message-ID (diff)
From: keescook@chromium.org (Kees Cook) To: linux-security-module@vger.kernel.org Subject: [PATCH v4 11/15] exec: Use secureexec for clearing pdeath_signal Date: Mon, 31 Jul 2017 16:51:29 -0700 [thread overview] Message-ID: <1501545093-56634-12-git-send-email-keescook@chromium.org> (raw) In-Reply-To: <1501545093-56634-1-git-send-email-keescook@chromium.org> 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); + 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. Cc: David Howells <dhowells@redhat.com> Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Serge Hallyn <serge@hallyn.com> --- fs/exec.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/exec.c b/fs/exec.c index f9997ea6414e..708a72f93320 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1348,8 +1348,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) -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-07-31 23:52 UTC|newest] Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-07-31 23:51 [PATCH v4 00/15] exec: Use sane stack rlimit under secureexec Kees Cook 2017-07-31 23:51 ` Kees Cook 2017-07-31 23:51 ` [PATCH v4 01/15] exec: Rename bprm->cred_prepared to called_set_creds Kees Cook 2017-07-31 23:51 ` Kees Cook 2017-07-31 23:51 ` [PATCH v4 02/15] exec: Correct comments about "point of no return" Kees Cook 2017-07-31 23:51 ` Kees Cook 2017-07-31 23:51 ` [PATCH v4 03/15] binfmt: Introduce secureexec flag Kees Cook 2017-07-31 23:51 ` Kees Cook 2017-08-01 0:23 ` Kees Cook 2017-08-01 0:23 ` Kees Cook 2017-08-01 0:44 ` James Morris 2017-08-01 0:44 ` James Morris 2017-07-31 23:51 ` [PATCH v4 04/15] apparmor: Refactor to remove bprm_secureexec hook Kees Cook 2017-07-31 23:51 ` Kees Cook 2017-07-31 23:51 ` [PATCH v4 05/15] selinux: " Kees Cook 2017-07-31 23:51 ` Kees Cook 2017-08-01 0:45 ` James Morris 2017-08-01 0:45 ` James Morris 2017-08-01 13:24 ` Andy Lutomirski 2017-08-01 13:24 ` Andy Lutomirski 2017-07-31 23:51 ` [PATCH v4 06/15] smack: " Kees Cook 2017-07-31 23:51 ` Kees Cook 2017-08-01 0:46 ` James Morris 2017-08-01 0:46 ` James Morris 2017-08-01 15:24 ` Casey Schaufler 2017-08-01 15:24 ` Casey Schaufler 2017-07-31 23:51 ` [PATCH v4 07/15] commoncap: " Kees Cook 2017-07-31 23:51 ` Kees Cook 2017-07-31 23:51 ` [PATCH v4 08/15] commoncap: Move cap_elevated calculation into bprm_set_creds Kees Cook 2017-07-31 23:51 ` Kees Cook 2017-08-01 13:46 ` Andy Lutomirski 2017-08-01 13:46 ` Andy Lutomirski 2017-07-31 23:51 ` [PATCH v4 09/15] LSM: drop bprm_secureexec hook Kees Cook 2017-07-31 23:51 ` Kees Cook 2017-07-31 23:51 ` [PATCH v4 10/15] exec: Use secureexec for setting dumpability Kees Cook 2017-07-31 23:51 ` Kees Cook 2017-08-01 0:48 ` James Morris 2017-08-01 0:48 ` James Morris 2017-07-31 23:51 ` Kees Cook [this message] 2017-07-31 23:51 ` [PATCH v4 11/15] exec: Use secureexec for clearing pdeath_signal Kees Cook 2017-08-01 0:50 ` James Morris 2017-08-01 0:50 ` James Morris 2017-07-31 23:51 ` [PATCH v4 12/15] smack: Remove redundant pdeath_signal clearing Kees Cook 2017-07-31 23:51 ` Kees Cook 2017-08-01 0:50 ` James Morris 2017-08-01 0:50 ` James Morris 2017-08-01 15:24 ` Casey Schaufler 2017-08-01 15:24 ` Casey Schaufler 2017-07-31 23:51 ` [PATCH v4 13/15] exec: Consolidate dumpability logic Kees Cook 2017-07-31 23:51 ` Kees Cook 2017-07-31 23:51 ` [PATCH v4 14/15] exec: Use sane stack rlimit under secureexec Kees Cook 2017-07-31 23:51 ` Kees Cook 2017-07-31 23:51 ` [PATCH v4 15/15] exec: Consolidate pdeath_signal clearing Kees Cook 2017-07-31 23:51 ` Kees Cook 2017-08-01 0:52 ` James Morris 2017-08-01 0:52 ` James Morris 2017-08-01 0:34 ` [PATCH v4 00/15] exec: Use sane stack rlimit under secureexec Kees Cook 2017-08-01 0:34 ` Kees Cook 2017-08-01 0:54 ` James Morris 2017-08-01 0:54 ` James Morris 2017-08-01 3:03 ` Kees Cook 2017-08-01 3:03 ` Kees Cook 2017-08-01 5:11 ` Linus Torvalds 2017-08-01 5:11 ` Linus Torvalds 2017-08-01 5:14 ` Linus Torvalds 2017-08-01 5:14 ` Linus Torvalds 2017-08-01 15:04 ` Kees Cook 2017-08-01 15:04 ` Kees Cook 2017-08-01 20:19 ` Linus Torvalds 2017-08-01 20:19 ` Linus Torvalds 2017-08-01 21:04 ` Kees Cook 2017-08-01 21:04 ` Kees Cook
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1501545093-56634-12-git-send-email-keescook@chromium.org \ --to=keescook@chromium.org \ --cc=akpm@linux-foundation.org \ --cc=casey@schaufler-ca.com \ --cc=dhowells@redhat.com \ --cc=ebiederm@xmission.com \ --cc=james.l.morris@oracle.com \ --cc=john.johansen@canonical.com \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=luto@kernel.org \ --cc=paul@paul-moore.com \ --cc=penguin-kernel@i-love.sakura.ne.jp \ --cc=sds@tycho.nsa.gov \ --cc=serge@hallyn.com \ --cc=torvalds@linux-foundation.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.