| Message ID | 87y2pcvz3b.fsf_-_@x220.int.ebiederm.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [01/11] exec: Reduce bprm->per_clear to a single bit | expand |
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
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
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:
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(-)