From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.kernel.org ([198.145.29.99]:60608 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933740AbdGTEyB (ORCPT ); Thu, 20 Jul 2017 00:54:01 -0400 Received: from mail-ua0-f170.google.com (mail-ua0-f170.google.com [209.85.217.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E076D22C97 for ; Thu, 20 Jul 2017 04:54:00 +0000 (UTC) Received: by mail-ua0-f170.google.com with SMTP id 35so14696855uax.3 for ; Wed, 19 Jul 2017 21:54:00 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1500416736-49829-1-git-send-email-keescook@chromium.org> <1500416736-49829-7-git-send-email-keescook@chromium.org> From: Andy Lutomirski Date: Wed, 19 Jul 2017 21:53:39 -0700 Message-ID: Subject: Re: [PATCH v3 06/15] commoncap: Refactor to remove bprm_secureexec hook To: Andy Lutomirski Cc: Kees Cook , Andrew Morton , Serge Hallyn , David Howells , "Eric W. Biederman" , John Johansen , Paul Moore , Stephen Smalley , Casey Schaufler , Tetsuo Handa , James Morris , Linus Torvalds , Linux FS Devel , LSM List , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, Jul 18, 2017 at 6:10 PM, Andy Lutomirski wrote: > On Tue, Jul 18, 2017 at 3:25 PM, Kees Cook wrote: >> The commoncap implementation of the bprm_secureexec hook is the only LSM >> that depends on the final call to its bprm_set_creds hook (since it may >> be called for multiple files, it ignores bprm->called_set_creds). As a >> result, it cannot safely _clear_ bprm->secureexec since other LSMs may >> have set it. Instead, remove the bprm_secureexec hook by introducing a >> new flag to bprm specific to commoncap: cap_elevated. This is similar to >> cap_effective, but that is used for a specific subset of elevated >> privileges, and exists solely to track state from bprm_set_creds to >> bprm_secureexec. As such, it will be removed in the next patch. >> >> Here, set the new bprm->cap_elevated flag when setuid/setgid has happened >> from bprm_fill_uid() or fscapabilities have been prepared. This temporarily >> moves the bprm_secureexec hook to a static inline. The helper will be >> removed in the next patch; this makes the step easier to review and bisect, >> since this does not introduce any changes to inputs nor outputs to the >> "elevated privileges" calculation. >> >> The new flag is merged with the bprm->secureexec flag in setup_new_exec() >> since this marks the end of any further prepare_binprm() calls. > > Reviewed-by: Andy Lutomirski > > with the redundant caveat that... > >> --- a/fs/exec.c >> +++ b/fs/exec.c >> @@ -1330,6 +1330,13 @@ EXPORT_SYMBOL(would_dump); >> >> void setup_new_exec(struct linux_binprm * bprm) >> { >> + /* >> + * Once here, prepare_binrpm() will not be called any more, so >> + * the final state of setuid/setgid/fscaps can be merged into the >> + * secureexec flag. >> + */ >> + bprm->secureexec |= bprm->cap_elevated; >> + > > ...the weird placement of the other assignments to bprm->secureexec > makes this exceedingly confusing. Can you just put the bprm->secureexec |= security_bprm_secureexec(bprm); assignment in prepare_binprm() right after security_bprm_set_creds()? This would make patch 1 make sense and make this make sense too, I think. Or is there some reason why it wouldn't work? If the latter, I think the patch descriptions and comments should maybe be fixed up.