linux-security-module November 2007 archive
Main Archive Page > Month Archives  > linux-security-module archives
linux-security-module: Re: [PATCH] 64bit capability support (leg

Re: [PATCH] 64bit capability support (legacy support fix)

From: Serge E. Hallyn <serue_at_nospam>
Date: Tue Nov 20 2007 - 02:35:01 GMT
To: Andrew Morgan <morgan@kernel.org>


Quoting Andrew Morgan (morgan@kernel.org):
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Andrew,
>
> The attached patch (171282b3553fcec43b9ab615eb7daf6c2b494a87) applies
> against 2.6.24-rc2-mm1. It addresses the problem reported by Kevin and
> Andy - ultimately, the legacy support wasn't transparent. In particular,
> userspace 32-bit capability manipulations (when run by root) that used
> to work, without this patch, fail.
>
> Cheers
>
> Andrew
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFHP8zBQheEq9QabfIRAs6/AJ9Tbn9vk/pgpu0FwOzU/EJg9oirjACaAndU
> unbe82Ep+s/y0Nl3aKP92uY=
> =8pOC
> -----END PGP SIGNATURE-----

> >From 171282b3553fcec43b9ab615eb7daf6c2b494a87 Mon Sep 17 00:00:00 2001
> From: Andrew G. Morgan <morgan@kernel.org>
> Date: Sat, 17 Nov 2007 21:03:19 -0800
> Subject: [PATCH] Legacy support fix; retain transparent support for 32-bit capability apps.
>
> Legacy support requires that we don't return an error for previously
> legitimate calls. Removing this check, we make a fail-safe best effort
> to support legacy applications.

Yeah, I struggled with this too.

This behavior makes particular sense if we think (as I do) that new capabilities will mainly be introduced along with new features. So legacy applications shouldn't misbehave due to ignorance or absence (after capget+capset) of them.

> Signed-off-by: Andrew G. Morgan <morgan@kernel.org>

Acked-by: Serge Hallyn <serue@us.ibm.com>

thanks,
-serge

> ---
> kernel/capability.c | 27 ++++++++++++++++++++-------
> 1 files changed, 20 insertions(+), 7 deletions(-)
>
> diff --git a/kernel/capability.c b/kernel/capability.c
> index 8cba9b2..9f2db55 100644
> --- a/kernel/capability.c
> +++ b/kernel/capability.c
> @@ -109,13 +109,26 @@ out:
> kdata[i].permitted = pP.cap[i];
> kdata[i].inheritable = pI.cap[i];
> }
> - while (i < _LINUX_CAPABILITY_U32S) {
> - if (pE.cap[i] || pP.cap[i] || pP.cap[i]) {
> - /* Cannot represent w/ legacy structure */
> - return -ERANGE;
> - }
> - i++;
> - }
> +
> + /*
> + * Note, in the case, tocopy < _LINUX_CAPABILITY_U32S,
> + * we silently drop the upper capabilities here. This
> + * has the effect of making older libcap
> + * implementations implicitly drop upper capability
> + * bits when they perform a: capget/modify/capset
> + * sequence.
> + *
> + * This behavior is considered fail-safe
> + * behavior. Upgrading the application to a newer
> + * version of libcap will enable access to the newer
> + * capabilities.
> + *
> + * An alternative would be to return an error here
> + * (-ERANGE), but that causes legacy applications to
> + * unexpectidly fail; the capget/modify/capset aborts
> + * before modification is attempted and the application
> + * fails.
> + */
>
> if (copy_to_user(dataptr, kdata, tocopy
> * sizeof(struct __user_cap_data_struct))) {
> --
> 1.5.1.3
>

-
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html