[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87k10wysqz.fsf_-_@x220.int.ebiederm.org>
Date: Thu, 28 May 2020 10:38:28 -0500
From: ebiederm@...ssion.com (Eric W. Biederman)
To: <linux-kernel@...r.kernel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Oleg Nesterov <oleg@...hat.com>, Jann Horn <jannh@...gle.com>,
Kees Cook <keescook@...omium.org>,
Greg Ungerer <gerg@...ux-m68k.org>,
Rob Landley <rob@...dley.net>,
Bernd Edlinger <bernd.edlinger@...mail.de>,
<linux-fsdevel@...r.kernel.org>, Al Viro <viro@...IV.linux.org.uk>,
Alexey Dobriyan <adobriyan@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Casey Schaufler <casey@...aufler-ca.com>,
linux-security-module@...r.kernel.org,
James Morris <jmorris@...ei.org>,
"Serge E. Hallyn" <serge@...lyn.com>,
Andy Lutomirski <luto@...capital.net>
Subject: [PATCH 0/11] exec: cred calculation simplifications
Recomputing the uids, gids, capabilities, and related flags each time a
new bprm->file is set is error prone, and as it turns out unnecessary.
Further our decisions on when to clear personality bits and when to tell
userspace privileges have been gained so please be extra careful, is
imperfect and our current code overshoots in inconsistent ways making
it hard to understand what is happening, and why.
Building upon my previous exec clean up work this set of changes moves
the bprm->cred calculations a little later so they only need to be done
once, moves all of the uid and gid handling into bprm_fill_uid, and
then cleans up setting secureexec and per_clear so they happen when they
make sense from a semantic perspective.
One of the largest challenges is dealing with how we revert the
credential change if it is discovered the process calling exec is
ptraced and the tracer does not have enough credentials. It looks
like that code was tacked on as an after thought to a bug fix that
went into 2.4.0-prerelease.
I don't know if we have ever gotten all of the details just right when
the credentials are rolled back. So this set of changes causes the
credentials not to be changed when ptraced, instead of attempting to
rollback the credential change.
Folks please give this code a review and let me know if you see
anything.
Eric W. Biederman (11):
exec: Reduce bprm->per_clear to a single bit
exec: Introduce active_per_clear the per file version of per_clear
exec: Compute file based creds only once
exec: Move uid/gid handling from creds_from_file into bprm_fill_uid
exec: In bprm_fill_uid use CAP_SETGID to see if a gid change is safe
exec: Don't set secureexec when the uid or gid changes are abandoned
exec: Set saved, fs, and effective ids together in bprm_fill_uid
exec: In bprm_fill_uid remove unnecessary no new privs check
exec: In bprm_fill_uid only set per_clear when honoring suid or sgid
exec: In bprm_fill_uid set secureexec at same time as per_clear
exec: Remove the label after_setid from bprm_fill_uid
fs/binfmt_misc.c | 2 +-
fs/exec.c | 95 +++++++++++++++++++++++++------------------
include/linux/binfmts.h | 13 +++---
include/linux/lsm_hook_defs.h | 2 +-
include/linux/lsm_hooks.h | 21 ++++++----
include/linux/security.h | 8 ++--
security/apparmor/domain.c | 2 +-
security/commoncap.c | 37 ++++++-----------
security/security.c | 4 +-
security/selinux/hooks.c | 2 +-
security/smack/smack_lsm.c | 2 +-
11 files changed, 98 insertions(+), 90 deletions(-)
---
This builds upon my previous exec cleanup work at:
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git exec-next
Thank you,
Eric
Powered by blists - more mailing lists