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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <871rn6a6e5.fsf@x220.int.ebiederm.org>
Date:   Tue, 26 May 2020 13:38:26 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     <linux-kernel@...r.kernel.org>, Andy Lutomirski <luto@...nel.org>,
        Christoph Lameter <cl@...ux.com>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Kees Cook <keescook@...omium.org>,
        Andy Lutomirski <luto@...capital.net>
Subject: [GIT PULL] Please pull exec fix for v5.7

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@...ssion.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@...r.kernel.org
Cc: Andy Lutomirski <luto@...nel.org>
Fixes: 58319057b784 ("capabilities: ambient capabilities")
Signed-off-by: "Eric W. Biederman" <ebiederm@...ssion.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