DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ECFE522C9E
MIME-Version: 1.0
In-Reply-To: <CALCETrVwR580iJA-Wb=-Do+XhyfQhefp6R7Hxy=TLE53hMvFvw@mail.gmail.com>
References: <1500416736-49829-1-git-send-email-keescook@chromium.org>
 <1500416736-49829-7-git-send-email-keescook@chromium.org> <CALCETrVwR580iJA-Wb=-Do+XhyfQhefp6R7Hxy=TLE53hMvFvw@mail.gmail.com>
From: Andy Lutomirski <luto@kernel.org>
Date: Wed, 19 Jul 2017 21:53:39 -0700
Message-ID: <CALCETrVjCgcGvHberis3eiGDf6S4gVyp5EGdpsK4giibssAooQ@mail.gmail.com>
Subject: Re: [PATCH v3 06/15] commoncap: Refactor to remove bprm_secureexec hook
To: Andy Lutomirski <luto@kernel.org>
Cc: Kees Cook <keescook@chromium.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Serge Hallyn <serge@hallyn.com>, David Howells <dhowells@redhat.com>,
        "Eric W. Biederman" <ebiederm@xmission.com>,
        John Johansen <john.johansen@canonical.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>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Linux FS Devel <linux-fsdevel@vger.kernel.org>,
        LSM List <linux-security-module@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2346
Lines: 49

On Tue, Jul 18, 2017 at 6:10 PM, Andy Lutomirski <luto@kernel.org> wrote:
> On Tue, Jul 18, 2017 at 3:25 PM, Kees Cook <keescook@chromium.org> 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 <luto@kernel.org>
>
> 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.