All of lore.kernel.org
 help / color / mirror / Atom feed
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.