From: "Andrew G. Morgan" <morgan@kernel.org>
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org
Subject: Re: [PATCH 4/6] file capabilities: clean up setcap code
Date: Fri, 26 Sep 2008 21:58:22 -0700 [thread overview]
Message-ID: <48DDBD6E.1070108@kernel.org> (raw)
In-Reply-To: <c9c64bbdfd3f1c665f0d1b08b82f77622be701cc.1222451103.git.serue@us.ibm.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Serge,
I have to say I'm a bit confused by this one. Specifically, the
cap_get_target_pid() change. In your 5/6 patch, you say this change
("the previous patch") makes the kernel bigger? Is this because of the
cap_get_target_pid() changes? Since you are fighting to reduce space, if
it bloats the code does the cap_get_target_pid() part of the change make
sense?
Cheers
Andrew
Serge E. Hallyn wrote:
> Clean up the sys_capset codepath a bit to account for the fact
> that you can now not ever, never, capset on another task.
>
> Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
> ---
> kernel/capability.c | 83 +++++++++++++++++++-------------------------------
> 1 files changed, 32 insertions(+), 51 deletions(-)
>
> diff --git a/kernel/capability.c b/kernel/capability.c
> index d39c989..92dd85b 100644
> --- a/kernel/capability.c
> +++ b/kernel/capability.c
> @@ -132,46 +132,31 @@ static int cap_validate_magic(cap_user_header_t header, unsigned *tocopy)
> * process. The net result is that we can limit our use of locks to
> * when we are reading the caps of another process.
> */
> -static inline int cap_get_target_pid(pid_t pid, kernel_cap_t *pEp,
> +static int cap_get_target_pid(pid_t pid, kernel_cap_t *pEp,
> kernel_cap_t *pIp, kernel_cap_t *pPp)
> {
> int ret;
> + struct task_struct *target;
>
> - if (pid && (pid != task_pid_vnr(current))) {
> - struct task_struct *target;
> + if (!pid || pid == task_pid_vnr(current))
> + return security_capget(current, pEp, pIp, pPp);
>
> - spin_lock(&task_capability_lock);
> - read_lock(&tasklist_lock);
> + spin_lock(&task_capability_lock);
> + read_lock(&tasklist_lock);
>
> - target = find_task_by_vpid(pid);
> - if (!target)
> - ret = -ESRCH;
> - else
> - ret = security_capget(target, pEp, pIp, pPp);
> + target = find_task_by_vpid(pid);
> + if (!target)
> + ret = -ESRCH;
> + else
> + ret = security_capget(target, pEp, pIp, pPp);
>
> - read_unlock(&tasklist_lock);
> - spin_unlock(&task_capability_lock);
> - } else
> - ret = security_capget(current, pEp, pIp, pPp);
> + read_unlock(&tasklist_lock);
> + spin_unlock(&task_capability_lock);
>
> return ret;
> }
>
> /*
> - * With filesystem capability support configured, the kernel does not
> - * permit the changing of capabilities in one process by another
> - * process. (CAP_SETPCAP has much less broad semantics when configured
> - * this way.)
> - */
> -static inline int do_sys_capset_other_tasks(pid_t pid,
> - kernel_cap_t *effective,
> - kernel_cap_t *inheritable,
> - kernel_cap_t *permitted)
> -{
> - return -EPERM;
> -}
> -
> -/*
> * Atomically modify the effective capabilities returning the original
> * value. No permission check is performed here - it is assumed that the
> * caller is permitted to set the desired effective capabilities.
> @@ -293,6 +278,9 @@ asmlinkage long sys_capset(cap_user_header_t header, const cap_user_data_t data)
> if (get_user(pid, &header->pid))
> return -EFAULT;
>
> + if (pid && (pid != task_pid_vnr(current)))
> + return -EPERM;
> +
> if (copy_from_user(&kdata, data, tocopy
> * sizeof(struct __user_cap_data_struct))) {
> return -EFAULT;
> @@ -310,30 +298,23 @@ asmlinkage long sys_capset(cap_user_header_t header, const cap_user_data_t data)
> i++;
> }
>
> - if (pid && (pid != task_pid_vnr(current)))
> - ret = do_sys_capset_other_tasks(pid, &effective, &inheritable,
> - &permitted);
> - else {
> - /*
> - * This lock is required even when filesystem
> - * capability support is configured - it protects the
> - * sys_capget() call from returning incorrect data in
> - * the case that the targeted process is not the
> - * current one.
> - */
> - spin_lock(&task_capability_lock);
> + /*
> + * This lock protects the sys_capget() call from
> + * returning incorrect data in the case that the targeted
> + * process is not the current one.
> + */
> + spin_lock(&task_capability_lock);
>
> - ret = security_capset_check(current, &effective, &inheritable,
> - &permitted);
> - /*
> - * Having verified that the proposed changes are
> - * legal, we now put them into effect.
> - */
> - if (!ret)
> - security_capset_set(current, &effective, &inheritable,
> - &permitted);
> - spin_unlock(&task_capability_lock);
> - }
> + ret = security_capset_check(current, &effective, &inheritable,
> + &permitted);
> + /*
> + * Having verified that the proposed changes are
> + * legal, we now put them into effect.
> + */
> + if (!ret)
> + security_capset_set(current, &effective, &inheritable,
> + &permitted);
> + spin_unlock(&task_capability_lock);
>
>
> return ret;
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFI3b1s+bHCR3gb8jsRAkWCAJ4j5Q5NQc2TD8B+WOYJ1JIqV1GdqQCg1qQU
+qzZPOvwo/W/73BuA+HvuxQ=
=fRje
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2008-09-27 4:59 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-27 2:27 [PATCH 0/6] file capabilities cleanups: introduction Serge E. Hallyn
2008-09-27 2:27 ` [PATCH 1/6] file capabilities: add no_file_caps switch (v3) Serge E. Hallyn
2008-09-27 2:27 ` [PATCH 2/6] file capabilities: remove CONFIG_SECURITY_FILE_CAPABILITIES Serge E. Hallyn
2008-09-27 4:25 ` Andrew G. Morgan
2008-09-27 2:27 ` [PATCH 3/6] file capabilities: uninline cap_safe_nice Serge E. Hallyn
2008-09-27 4:26 ` Andrew G. Morgan
2008-09-27 5:27 ` James Morris
2008-09-27 2:27 ` [PATCH 4/6] file capabilities: clean up setcap code Serge E. Hallyn
2008-09-27 4:58 ` Andrew G. Morgan [this message]
2008-09-27 13:43 ` Serge E. Hallyn
2008-09-27 2:27 ` [PATCH 5/6] file capabilities: remove needless inline functions Serge E. Hallyn
2008-09-27 4:39 ` Andrew G. Morgan
2008-09-27 13:40 ` Serge E. Hallyn
2008-09-29 21:53 ` Serge E. Hallyn
2008-09-27 2:27 ` [PATCH 6/6] file capabilities: remove needless (?) bprm_clear_caps calls Serge E. Hallyn
2008-09-27 2:27 ` Serge E. Hallyn
2008-09-27 2:27 ` 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=48DDBD6E.1070108@kernel.org \
--to=morgan@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--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 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.