From: Andrew Morgan <morgan@kernel.org>
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: Chris Wright <chrisw@sous-sol.org>,
casey@schaufler-ca.com, Andrew Morton <akpm@google.com>,
Stephen Smalley <sds@tycho.nsa.gov>,
KaiGai Kohei <kaigai@kaigai.gr.jp>,
James Morris <jmorris@namei.org>,
linux-security-module@vger.kernel.org,
Linux Containers <containers@lists.osdl.org>
Subject: Re: [PATCH 1/1] capabilities: introduce per-process capability bounding set (v8)
Date: Mon, 19 Nov 2007 21:37:03 -0800 [thread overview]
Message-ID: <4742727F.6030104@kernel.org> (raw)
In-Reply-To: <47425727.10702@kernel.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andrew Morgan wrote:
>> + current->cap_effective = cap_intersect(current->cap_effective,
>> + current->cap_bset);
>> + current->cap_permitted = cap_intersect(current->cap_permitted,
>> + current->cap_bset);
>> + current->cap_inheritable = cap_intersect(current->cap_inheritable,
>> + current->cap_bset);
>
> You might want to replace the above three lines with a restriction
> elsewhere on what CAP_SETPCAP can newly set in
> commoncap.c:cap_capset_check().
>
> That is, CAP_SETPCAP permits the current process to raise 'any' pI
> capability. I suspect that you'll want to prevent raising any bits not
> masked by this:
>
> pI' & ~(pI | (pP & cap_bset)).
On second thoughts, I really meant this:
diff --git a/security/commoncap.c b/security/commoncap.c
index 302e8d0..b28c0c1 100644
- --- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -133,6 +133,12 @@ int cap_capset_check (struct task_struct *target,
kernel_ca /* incapable of using this inheritable set */
return -EPERM;
}
+ if (!cap_issubset(*inheritable,
+ cap_combine(target->cap_inheritable,
+ current->cap_bset))) {
+ /* no new pI capabilities outside bounding set */
+ return -EPERM;
+ }
/* verify restrictions on target's new Permitted set */
if (!cap_issubset (*permitted,
Cheers
Andrew
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFHQnJ8QheEq9QabfIRAl2rAJ4jH+l36N1+cHV+1A3DJpXs+UNsFgCgkg8H
xOU/7dCrEq02xk9EgcRarg0=
=FbqU
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2007-11-20 5:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20071119212519.GA23178@sergelap.austin.ibm.com>
2007-11-20 3:40 ` [PATCH 1/1] capabilities: introduce per-process capability bounding set (v8) Andrew Morgan
2007-11-20 5:37 ` Andrew Morgan [this message]
2007-11-20 18:14 ` Serge E. Hallyn
[not found] ` <20071120181452.GA10765-6s5zFf/epYLPQpwDFJZrxKsjOiXwFzmk@public.gmane.org>
2007-11-20 18:32 ` Serge E. Hallyn
2007-11-22 7:10 ` Andrew Morgan
2007-11-20 20:07 ` Serge E. Hallyn
2007-11-20 20:23 ` Serge E. Hallyn
2007-11-22 6:41 ` Andrew Morgan
2007-11-19 21:25 Serge E. Hallyn
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=4742727F.6030104@kernel.org \
--to=morgan@kernel.org \
--cc=akpm@google.com \
--cc=casey@schaufler-ca.com \
--cc=chrisw@sous-sol.org \
--cc=containers@lists.osdl.org \
--cc=jmorris@namei.org \
--cc=kaigai@kaigai.gr.jp \
--cc=linux-security-module@vger.kernel.org \
--cc=sds@tycho.nsa.gov \
--cc=serue@us.ibm.com \
/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