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

2007-11-21 Thread Andrew Morton 
On Wed, 21 Nov 2007 11:10:51 -0600
Serge E. Hallyn [EMAIL PROTECTED] wrote:

 Quoting Andrew Morton ([EMAIL PROTECTED]):
  On Sat, 17 Nov 2007 21:25:27 -0800 Andrew Morgan [EMAIL PROTECTED] wrote:
  
   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.
  
  My venerable FC1 machine says
  
  warning: process `zsh' gets w/ old libcap
  warning: process `zsh' gets w/ old libcap
  warning: process `zsh' gets w/ old libcap
  
  should I be scared?
 
 It should be safe as of Andrew's latest patch.  (Before that patch it
 was only unsafe because root's capabilities are just set to {~0,~0} so
 they include invalid capabilities.
 
 Agreed a better error message would be good.

yup

  Would it be inappropriate
 to include the URL for new libcap versions?

I doubt it, really.  Anyone who's running anything as old as FC1 won't be
upgrading (and probably couldn't find a package to upgrade to).

Or does old libcap here refer to all the versions whcih are deployed
today?  If so then we should jsut kill the message.  ot at least make it a
once-per-boot thing.


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

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

2007-11-20 Thread Andrew Morton 
On Sat, 17 Nov 2007 21:25:27 -0800 Andrew Morgan [EMAIL PROTECTED] wrote:

 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.

My venerable FC1 machine says

warning: process `zsh' gets w/ old libcap
warning: process `zsh' gets w/ old libcap
warning: process `zsh' gets w/ old libcap

should I be scared?
-
To unsubscribe from this list: send the line unsubscribe 
linux-security-module in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2007-11-19 Thread Serge E. Hallyn 
Quoting Andrew Morgan ([EMAIL PROTECTED]):
 -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 [EMAIL PROTECTED]
 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 [EMAIL PROTECTED]

Acked-by: Serge Hallyn [EMAIL PROTECTED]

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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2007-11-18 Thread Kevin Winchester 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andrew Morgan wrote:
 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.
 

This works for me.  I guess the appropriate line is:

Tested-by: Kevin Winchester [EMAIL PROTECTED]


- --
Kevin Winchester
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHQHkqKPGFQbiQ3tQRAt/uAJ9bWz4XHFDkavlCsl4wyT91KXa5GQCfZ3t1
4fy44s2RVnNDQaVJasf4OF0=
=QMO4
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line unsubscribe 
linux-security-module in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2007-11-17 Thread Andrew Morgan 
-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 [EMAIL PROTECTED]
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.

Signed-off-by: Andrew G. Morgan [EMAIL PROTECTED]
---
 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