[GIT PULL] Please pull exec fix for v5.7

[GIT PULL] Please pull exec fix for v5.7

[Eric W. Biederman]

Please pull the exec-linus branch from the git tree:

   git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git exec-linus

   HEAD: a4ae32c71fe90794127b32d26d7ad795813b502e exec: Always set cap_ambient in cap_bprm_set_creds

While working on my exec cleanups I found a bug in exec that winds
up miscomputing the ambient credentials during exec.  Andy appears
as to credentials are computed for both the script and the interpreter.

From the original patch description:

[3] Linux very confusingly processes both the script and the interpreter
    if applicable, for reasons that elude me.  The results from thinking
    about a script's file capabilities and/or setuid bits are mostly
    discarded.

The only value in struct cred that gets changed in cap_bprm_set_creds
that I could find that might persist between the script and the
interpreter was cap_ambient.  Which is fixed with this trivial change.

Eric

From: "Eric W. Biederman" <ebiederm@xmission.com>
Date: Mon, 25 May 2020 12:56:15 -0500
Subject: [PATCH] exec: Always set cap_ambient in cap_bprm_set_creds

An invariant of cap_bprm_set_creds is that every field in the new cred
structure that cap_bprm_set_creds might set, needs to be set every
time to ensure the fields does not get a stale value.

The field cap_ambient is not set every time cap_bprm_set_creds is
called, which means that if there is a suid or sgid script with an
interpreter that has neither the suid nor the sgid bits set the
interpreter should be able to accept ambient credentials.
Unfortuantely because cap_ambient is not reset to it's original value
the interpreter can not accept ambient credentials.

Given that the ambient capability set is expected to be controlled by
the caller, I don't think this is particularly serious.  But it is
definitely worth fixing so the code works correctly.

I have tested to verify my reading of the code is correct and the
interpreter of a sgid can receive ambient capabilities with this
change and cannot receive ambient capabilities without this change.

Cc: stable@vger.kernel.org
Cc: Andy Lutomirski <luto@kernel.org>
Fixes: 58319057b784 ("capabilities: ambient capabilities")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
 security/commoncap.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/security/commoncap.c b/security/commoncap.c
index f4ee0ae106b2..0ca31c8bc0b1 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -812,6 +812,7 @@ int cap_bprm_set_creds(struct linux_binprm *bprm)
 	int ret;
 	kuid_t root_uid;
 
+	new->cap_ambient = old->cap_ambient;
 	if (WARN_ON(!cap_ambient_invariant_ok(old)))
 		return -EPERM;
 
-- 
2.20.1

Re: [GIT PULL] Please pull exec fix for v5.7

[Linus Torvalds]

On Tue, May 26, 2020 at 11:42 AM Eric W. Biederman
<ebiederm@xmission.com> wrote:
>
> While working on my exec cleanups I found a bug in exec that winds
> up miscomputing the ambient credentials during exec.  Andy appears
> as to credentials are computed for both the script and the interpreter.

Can you rephrase that?

I tried to figure out what you were trying to say, and I can't. I
suspect a whole line or two is missing, or you were re-writing that
thing and stopped in the middle or something.

I'm also somewhat confused by your placement of that

        new->cap_ambient = old->cap_ambient;

which doesn't seem to make a lot of sense. It's before the code even
checks that the old ambient is valid, which I guess doesn't really
matter (an error is an error, and the newly set state will not be used
in that case), but aside from that it's just in an odd place.

It's not near any other code that affects the new capabilities.
Wouldn't it have made more sense to do this where we then clear
cap_ambient if it's a setid binary?

So this pull just confuses me for a couple of reasons - I'm not saying
it's wrong, but at a minimum I'd like to get a merge message that
makes more sense..

               Linus

Re: [GIT PULL] Please pull exec fix for v5.7

[Eric W. Biederman]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Tue, May 26, 2020 at 11:42 AM Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>>
>> While working on my exec cleanups I found a bug in exec that winds
>> up miscomputing the ambient credentials during exec.  Andy appears
>> as to credentials are computed for both the script and the interpreter.
>

> Can you rephrase that?

yes.

The sentence should have read: 
"Andy appears to have to been confused as to why credentials are computed
for both the script and the interpreter."

If that is not enough ask and I will rewrite and resend the pull
request.

> I tried to figure out what you were trying to say, and I can't. I
> suspect a whole line or two is missing, or you were re-writing that
> thing and stopped in the middle or something.
>
> I'm also somewhat confused by your placement of that
>
>         new->cap_ambient = old->cap_ambient;


I am restoring the work usually done by prepare_exec_creds, that
happens to get messed up when cap_bprm_set_creds is called multiple
times.

Since that happens before cap_brpm_set_creds is ever called I figured
doing it at the top of the function in case there is something subtle
is the path to safety and reliability, especially if the code will
be backported.

I don't see us touching cap_ambient anywhere except the line that does:

	/* File caps or setid cancels ambient. */
	if (has_fcap || is_setid)
		cap_clear(new->cap_ambient);

But I am human and miss things occasionally.

> which doesn't seem to make a lot of sense. It's before the code even
> checks that the old ambient is valid, which I guess doesn't really
> matter (an error is an error, and the newly set state will not be used
> in that case), but aside from that it's just in an odd place.
>
> It's not near any other code that affects the new capabilities.
> Wouldn't it have made more sense to do this where we then clear
> cap_ambient if it's a setid binary?

That was my first thought but then I got defensive.

I think setting new->cap_ambient unconditionally at the top of the
function is the most robust way to code it. (see above).


The distance for other code clearing variables is also a mirage.  The
get_file_caps function 3 lines down in it's first line clears
new->cap_permitted.

> So this pull just confuses me for a couple of reasons - I'm not saying
> it's wrong, but at a minimum I'd like to get a merge message that
> makes more sense..

I am going to dash to get my allergy injection today, and then come
back and address whatever concerns you might have.

Eric

Re: [GIT PULL] Please pull exec fix for v5.7

[Linus Torvalds]

On Tue, May 26, 2020 at 1:36 PM Eric W. Biederman <ebiederm@xmission.com> wrote:
>
> I don't see us touching cap_ambient anywhere except the line that does:
>
>         /* File caps or setid cancels ambient. */
>         if (has_fcap || is_setid)
>                 cap_clear(new->cap_ambient);

That's the one I was thinking of.

I think it would have made more sense to simply initialize it there
and have all accesses to cap_ambient in one place.

The (even better?) alternative would have been to simply just always
re-initialize it in the caller.

If this is about interpreter vs scripts, I really find it confusing
how we make these kinds of re-initializations at the security layer
that doesn't know about one vs the other.. Yes, in your cleanup
branch, the "primary" thing becomes more clear, but it very much is
_not_ clear within the context of this patch.

Hmm?

              Linus

Re: [GIT PULL] Please pull exec fix for v5.7

[pr-tracker-bot]

The pull request you sent on Tue, 26 May 2020 13:38:26 -0500:

> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git exec-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/006f38a1c3dcbe237a75e725fe457bd59cb489c4

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [GIT PULL] Please pull exec fix for v5.7

[pr-tracker-bot]

The pull request you sent on Sun, 17 May 2020 11:05:35 -0500:

> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git exec-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b48397cb75ac17a5c6f99b3b41fab0ab1f879826

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

[GIT PULL] Please pull exec fix for v5.7

[Eric W. Biederman]

Linus,

Please pull the exec-linus branch from the git tree:

   git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git exec-linus

   HEAD: f87d1c9559164294040e58f5e3b74a162bf7c6e8 exec: Move would_dump into flush_old_exec

While working on my exec cleanups I found a bug in exec that I
introduced by accident a couple of years ago.  I apparently missed the
fact that bprm->file can change.

Now I have a very personal motive to clean up exec and make it more
approachable.

The change is just moving woud_dump to where it acts on the final
bprm->file not the initial bprm->file.   I have been careful and
tested and verify this fix works.

Eric

---

From f87d1c9559164294040e58f5e3b74a162bf7c6e8 Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm@xmission.com>
Date: Sat, 16 May 2020 16:29:20 -0500
Subject: [PATCH] exec: Move would_dump into flush_old_exec

I goofed when I added mm->user_ns support to would_dump.  I missed the
fact that in the case of binfmt_loader, binfmt_em86, binfmt_misc, and
binfmt_script bprm->file is reassigned.  Which made the move of
would_dump from setup_new_exec to __do_execve_file before exec_binprm
incorrect as it can result in would_dump running on the script instead
of the interpreter of the script.

The net result is that the code stopped making unreadable interpreters
undumpable.  Which allows them to be ptraced and written to disk
without special permissions.  Oops.

The move was necessary because the call in set_new_exec was after
bprm->mm was no longer valid.

To correct this mistake move the misplaced would_dump from
__do_execve_file into flos_old_exec, before exec_mmap is called.

I tested and confirmed that without this fix I can attach with gdb to
a script with an unreadable interpreter, and with this fix I can not.

Cc: stable@vger.kernel.org
Fixes: f84df2a6f268 ("exec: Ensure mm->user_ns contains the execed files")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
 fs/exec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/exec.c b/fs/exec.c
index 06b4c550af5d..2c465119affc 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1317,6 +1317,8 @@ int flush_old_exec(struct linux_binprm * bprm)
 	 */
 	set_mm_exe_file(bprm->mm, bprm->file);
 
+	would_dump(bprm, bprm->file);
+
 	/*
 	 * Release all of the old mmap stuff
 	 */
@@ -1876,8 +1878,6 @@ static int __do_execve_file(int fd, struct filename *filename,
 	if (retval < 0)
 		goto out;
 
-	would_dump(bprm, bprm->file);
-
 	retval = exec_binprm(bprm);
 	if (retval < 0)
 		goto out;
-- 
2.20.1