From: "Serge E. Hallyn" <serge@hallyn.com>
To: Andrew Morton <akpm@osdl.org>, Andrew Morgan <morgan@kernel.org>
Cc: Marcel Holtmann <marcel@holtmann.org>,
Michael Kerrisk <mtk-manpages@gmx.net>,
linux-kernel@vger.kernel.org,
Stephen Smalley <sds@epoch.ncsc.mil>
Subject: [PATCH -mm] capabilities: reset current->pdeath_signal when increasing capabilities
Date: Tue, 28 Aug 2007 13:45:22 -0500 [thread overview]
Message-ID: <20070828184522.GA24634@vino.hallyn.com> (raw)
I think the following does the right thing with respect to the
pdeath_signal bug and file capabilities. I somewhat question the need
to do this if we're just switching uid or gid (if running in strict
capability mode), but it seems prudent to just leave it right there.
Note that so far this is only need in -mm. Linus' tree will do the
right thing with the original pdeath patch since the only way to
increase capabilities is to first become root or run a setuid root
binary.
thanks,
-serge
>From 7e21df941dfb55c4fc19d82a91d6eae74766a2ec Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn <serue@us.ibm.com>
Date: Tue, 28 Aug 2007 14:32:35 -0400
Subject: [PATCH] capabilities: reset current->pdeath_signal when increasing capabilities
If running a program which has file capabilities which are not a subset
of the capabilities of the current task, reset pdeath_signal = 0 to
prevent the task parent from (deliberately) signaling a more privileged
app.
Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
---
security/commoncap.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/security/commoncap.c b/security/commoncap.c
index d65ddd3..43f9027 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -315,6 +315,7 @@ void cap_bprm_apply_creds (struct linux_binprm *bprm, int unsafe)
if (bprm->e_uid != current->uid || bprm->e_gid != current->gid ||
!cap_issubset (new_permitted, current->cap_permitted)) {
set_dumpable(current->mm, suid_dumpable);
+ current->pdeath_signal = 0;
if (unsafe & ~LSM_UNSAFE_PTRACE_CAP) {
if (!capable(CAP_SETUID)) {
--
1.5.1.1.GIT
reply other threads:[~2007-08-28 18:45 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=20070828184522.GA24634@vino.hallyn.com \
--to=serge@hallyn.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcel@holtmann.org \
--cc=morgan@kernel.org \
--cc=mtk-manpages@gmx.net \
--cc=sds@epoch.ncsc.mil \
/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
all inboxes | Powered by JetHome®