From: Kees Cook <keescook@chromium.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, Andy Lutomirski <luto@kernel.org>,
Casey Schaufler <casey@schaufler-ca.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
James Morris <james.l.morris@oracle.com>,
John Johansen <john.johansen@canonical.com>,
Kees Cook <keescook@chromium.org>,
Paul Moore <paul@paul-moore.com>, Serge Hallyn <serge@hallyn.com>
Subject: [GIT PULL] secureexec update for v4.14-rc1
Date: Tue, 5 Sep 2017 13:11:06 -0700 [thread overview]
Message-ID: <20170905201106.GA72566@beast> (raw)
Hi,
Please pull these secureexec changes for v4.14-rc1. Notes on the series
below.
Thanks!
-Kees
The following changes since commit 520eccdfe187591a51ea9ab4c1a024ae4d0f68d9:
Linux 4.13-rc2 (2017-07-23 16:15:17 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/secureexec-v4.14-rc1
for you to fetch changes up to fe8993b3a05cbba6318a54e0f85901aaea6fc244:
exec: Consolidate pdeath_signal clearing (2017-08-01 12:03:14 -0700)
----------------------------------------------------------------
This series has the ultimate goal of providing a sane stack rlimit when
running set*id processes. To do this, the bprm_secureexec LSM hook is
collapsed into the bprm_set_creds hook so the secureexec-ness of an exec
can be determined early enough to make decisions about rlimits and the
resulting memory layouts. Other logic acting on the secureexec-ness of an
exec is similarly consolidated. Capabilities needed some special handling,
but the refactoring removed other special handling, so that was a wash.
----------------------------------------------------------------
Kees Cook (15):
exec: Rename bprm->cred_prepared to called_set_creds
exec: Correct comments about "point of no return"
binfmt: Introduce secureexec flag
apparmor: Refactor to remove bprm_secureexec hook
selinux: Refactor to remove bprm_secureexec hook
smack: Refactor to remove bprm_secureexec hook
commoncap: Refactor to remove bprm_secureexec hook
commoncap: Move cap_elevated calculation into bprm_set_creds
LSM: drop bprm_secureexec hook
exec: Use secureexec for setting dumpability
exec: Use secureexec for clearing pdeath_signal
smack: Remove redundant pdeath_signal clearing
exec: Consolidate dumpability logic
exec: Use sane stack rlimit under secureexec
exec: Consolidate pdeath_signal clearing
fs/binfmt_elf.c | 2 +-
fs/binfmt_elf_fdpic.c | 2 +-
fs/binfmt_flat.c | 2 +-
fs/exec.c | 56 ++++++++++++++++++++++++++++----------
include/linux/binfmts.h | 24 ++++++++++++----
include/linux/lsm_hooks.h | 14 ++++------
include/linux/security.h | 7 -----
security/apparmor/domain.c | 21 ++------------
security/apparmor/include/domain.h | 1 -
security/apparmor/include/file.h | 3 --
security/apparmor/lsm.c | 1 -
security/commoncap.c | 50 ++++++++--------------------------
security/security.c | 5 ----
security/selinux/hooks.c | 26 ++++--------------
security/smack/smack_lsm.c | 34 ++---------------------
security/tomoyo/tomoyo.c | 2 +-
16 files changed, 91 insertions(+), 159 deletions(-)
--
Kees Cook
Pixel Security
reply other threads:[~2017-09-05 20:11 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170905201106.GA72566@beast \
--to=keescook@chromium.org \
--cc=casey@schaufler-ca.com \
--cc=ebiederm@xmission.com \
--cc=james.l.morris@oracle.com \
--cc=john.johansen@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=paul@paul-moore.com \
--cc=serge@hallyn.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox