[09/11] exec: In bprm_fill_uid only set per_clear when honoring suid or sgid
diff mbox series

Message ID 87y2pcvz3b.fsf_-_@x220.int.ebiederm.org
State New
Headers show
Series
  • [01/11] exec: Reduce bprm->per_clear to a single bit
Related show

Commit Message

Eric W. Biederman May 28, 2020, 3:49 p.m. UTC
It makes no sense to set active_per_clear when the kernel decides not
to honor the executables setuid or or setgid bits.  Instead set
active_per_clear when the kernel actually decides to honor the suid or
sgid permission bits of an executable.

As far as I can tell this was the intended behavior but with the
ptrace logic hiding out in security/commcap.c:cap_bprm_apply_creds I
believe it was just overlooked that the setuid or setgid operation
could be cancelled.

History Tree: git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Fixes: 1bb0fa189c6a ("[PATCH] NX: clean up legacy binary support")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
 fs/exec.c | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

Comments

Linus Torvalds May 28, 2020, 7:08 p.m. UTC | #1
On Thu, May 28, 2020 at 8:53 AM Eric W. Biederman <ebiederm@xmission.com> wrote:
>
> It makes no sense to set active_per_clear when the kernel decides not
> to honor the executables setuid or or setgid bits.  Instead set
> active_per_clear when the kernel actually decides to honor the suid or
> sgid permission bits of an executable.

You seem to be confused about the naming yourself.

You talk about "active_per_clear", but the code is about "per_clear". WTF?

              Linus
Eric W. Biederman May 28, 2020, 7:21 p.m. UTC | #2
Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Thu, May 28, 2020 at 8:53 AM Eric W. Biederman <ebiederm@xmission.com> wrote:
>>
>> It makes no sense to set active_per_clear when the kernel decides not
>> to honor the executables setuid or or setgid bits.  Instead set
>> active_per_clear when the kernel actually decides to honor the suid or
>> sgid permission bits of an executable.
>
> You seem to be confused about the naming yourself.
>
> You talk about "active_per_clear", but the code is about "per_clear". WTF?

I figured out how to kill active_per_clear see (3/11) and I failed to
update the patch description here.

I think active_ is a louzy suffix but since it all goes away in patch 3
when I remove the recomputation and the need to have two versions of the
setting I think it is probably good enough.

Eric

Patch
diff mbox series

diff --git a/fs/exec.c b/fs/exec.c
index af108ecf9632..347dade4bc54 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1634,15 +1634,16 @@  static void bprm_fill_uid(struct linux_binprm *bprm)
 	need_cap = bprm->unsafe & LSM_UNSAFE_SHARE ||
 		!ptracer_capable(current, new->user_ns);
 
-	if (mode & S_ISUID) {
+	if ((mode & S_ISUID) &&
+	    (!need_cap || ns_capable(new->user_ns, CAP_SETUID))) {
 		bprm->per_clear = 1;
-		if (!need_cap || ns_capable(new->user_ns, CAP_SETUID))
-			new->suid = new->fsuid = new->euid = uid;
+		new->suid = new->fsuid = new->euid = uid;
 	}
-	if ((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) {
+
+	if (((mode & (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) &&
+	    (!need_cap || ns_capable(new->user_ns, CAP_SETGID))) {
 		bprm->per_clear = 1;
-		if (!need_cap || ns_capable(new->user_ns, CAP_SETGID))
-			new->sgid = new->fsgid = new->egid = gid;
+		new->sgid = new->fsgid = new->egid = gid;
 	}
 
 after_setid: