Re: [PATCH] 64bit capability support (legacy support fix)
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
[PATCH] Modify 'old libcap' warning message
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrew,
Yes, as Kevin suggests 'old' meant 1.x, which is pretty much the only
version of libcap in wide distribution.
Libcap is available here:
http://www.kernel.org/pub/linux/libs/security/linux-privs/
Attached is a modification of the problematic kernel message - I had no
idea these messages would generate so much consternation. I've rewritten
it, but I'm not altogether clear what level of detail is
permitted/desirable. Is this ok?
Cheers
Andrew
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.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFHRRw3QheEq9QabfIRAm53AJ4kq+tZl1qx4pnDQpUB7I7QhHeYmQCeJfbu
WDayoZLfYsBrYhUilb9eEiQ=
=pwEc
-END PGP SIGNATURE-
From fd99fb6f41d04ecf37a61ae8ecc856e8ac686e91 Mon Sep 17 00:00:00 2001
From: Andrew G. Morgan [EMAIL PROTECTED]
Date: Wed, 21 Nov 2007 21:54:09 -0800
Subject: [PATCH] Clean up warning about legacy (32-bit) capability use
When an application (usually via libcap) attempts to use 32-bit
capabilities when the kernel supports 64-bit capabilities, we log a
kernel warning. We do this exactly once per kernel boot. The warning
is just that - the kernel should be able to transparently handle
32-bit capability use. The application will remain limited in the
capabilities that it can manipulate until it is relinked with libcap2.
Signed-off-by: Andrew G. Morgan [EMAIL PROTECTED]
---
kernel/capability.c | 36 ++--
1 files changed, 22 insertions(+), 14 deletions(-)
diff --git a/kernel/capability.c b/kernel/capability.c
index 9f2db55..e48192f 100644
--- a/kernel/capability.c
+++ b/kernel/capability.c
@@ -30,6 +30,26 @@ const kernel_cap_t __cap_full_set = CAP_FULL_SET;
const kernel_cap_t __cap_init_eff_set = CAP_INIT_EFF_SET;
/*
+ * More recent versions of libcap are available from:
+ *
+ * http://www.kernel.org/pub/linux/libs/security/linux-privs/
+ */
+
+static void warn_legacy_capability_use(void)
+{
+ static int warned = 0;
+ if (!warned) {
+ char name[sizeof(current-comm)];
+
+ printk(KERN_INFO warning: `%s' uses 32-bit capabilities
+ (legacy support in use)\n,
+ get_task_comm(name, current));
+ warned = 1;
+ }
+ return;
+}
+
+/*
* For sys_getproccap() and sys_setproccap(), any of the three
* capability set pointers may be NULL -- indicating that that set is
* uninteresting and/or not to be changed.
@@ -59,12 +79,7 @@ asmlinkage long sys_capget(cap_user_header_t header, cap_user_data_t dataptr)
switch (version) {
case _LINUX_CAPABILITY_VERSION_1:
- if (warned 5) {
- warned++;
- printk(KERN_INFO
- warning: process `%s' gets w/ old libcap\n,
- current-comm);
- }
+ warn_legacy_capability_use();
tocopy = _LINUX_CAPABILITY_U32S_1;
break;
case _LINUX_CAPABILITY_VERSION_2:
@@ -223,7 +238,6 @@ static inline int cap_set_all(kernel_cap_t *effective,
*/
asmlinkage long sys_capset(cap_user_header_t header, const cap_user_data_t data)
{
- static int warned;
struct __user_cap_data_struct kdata[_LINUX_CAPABILITY_U32S];
unsigned i, tocopy;
kernel_cap_t inheritable, permitted, effective;
@@ -237,13 +251,7 @@ asmlinkage long sys_capset(cap_user_header_t header, const cap_user_data_t data)
switch (version) {
case _LINUX_CAPABILITY_VERSION_1:
- if (warned 5) {
- char name[sizeof(current-comm)];
- warned++;
- printk(KERN_INFO
- warning: process `%s' sets w/ old libcap\n,
- get_task_comm(name, current));
- }
+ warn_legacy_capability_use();
tocopy = _LINUX_CAPABILITY_U32S_1;
break;
case _LINUX_CAPABILITY_VERSION_2:
--
1.5.1.3
Re: [PATCH 1/1] capabilities: introduce per-process capability bounding set (v8)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge,
16d76d11d27f32487366a7cec6a52f6ec4fb1cbb
+ 470a68120cda83875a281354b897f3bda04b58fc
Could you also modify the old comment above
#define CAP_SETPCAP 8
add any capability to the current process' inheritable set
to read
add any capability, from cap_bset, to the current process' inheritable set
Otherwise, this all looks good.
Thanks
Andrew
Serge E. Hallyn wrote:
Quoting Serge E. Hallyn ([EMAIL PROTECTED]):
How about the following?
Argh, with the following on top of it...
-serge
From 470a68120cda83875a281354b897f3bda04b58fc Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn [EMAIL PROTECTED]
Date: Tue, 20 Nov 2007 15:12:54 -0500
Subject: [PATCH 1/1] capbset: fix compilation when CONFIG_SECURITY=n
without this patch, kernel/sys.c has undefined reference
to cap_prctl_drop().
Signed-off-by: Serge E. Hallyn [EMAIL PROTECTED]
---
kernel/sys.c |4
security/commoncap.c |4
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/sys.c b/kernel/sys.c
index b528e75..efc495e 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1747,7 +1747,11 @@ asmlinkage long sys_prctl(int option, unsigned long
arg2, unsigned long arg3,
return -EINVAL;
return !!cap_raised(current-cap_bset, arg2);
case PR_CAPBSET_DROP:
+#ifdef CONFIG_SECURITY_FILE_CAPABILITIES
return cap_prctl_drop(arg2);
+#else
+ return -EINVAL;
+#endif
default:
error = -EINVAL;
diff --git a/security/commoncap.c b/security/commoncap.c
index b72825e..e909f4f 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -594,10 +594,6 @@ int cap_task_kill(struct task_struct *p, struct siginfo
*info,
{
return 0;
}
-long cap_prctl_drop(unsigned long cap)
-{
- return -EINVAL;
-}
#endif
void cap_task_reparent_to_init (struct task_struct *p)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFHRSSmQheEq9QabfIRAk8zAJ9u+RFKmZroCUIZzyHDX9XIP4v/EgCcCTJN
eGcNpqTMzOiLYwMGow3RAWQ=
=GSo6
-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
Re: [PATCH 1/1] capabilities: introduce per-process capability bounding set (v8)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Serge E. Hallyn wrote:
I worry that what you have is just a *touch* too busy so whoever adds
capability #32 might forget to update CAP_NUM_CAPS, but it looks like
#define CAP_LAST_CAP CAP_SETFCAP
#define cap_valid(x) ((x) = 0 (x) = CAP_LAST_CAP)
should also be ok for libcap.
FWIW libcap computes the upper limit itself in the process of consuming
all that sed'ed stuff. You do need it for the kernel, and this seems
like a fine mechanism.
+long cap_prctl_drop(unsigned long cap)
+{
+ if (!capable(CAP_SETPCAP))
+ return -EPERM;
+ if (!cap_valid(cap))
+ return -EINVAL;
+ cap_lower(current-cap_bset, cap);
I think the following lines are overkill. Basically, the next exec()
will perform the pP/pE clipping, and cap_bset should only interact with
fP (and not fI).
We already have a mechanism to manipulate pI, which in turn gates fI.
And this same mechanism (libcap) can clip pE, pP if it is needed pre-exec().
So, if you want to drop a capability irrevocably, you drop it in bset,
and separately in pI. The current process may continue to have the
capability, but post-exec the working process tree has lost it. For
things like login, this is desirable.
Ok...
I think this makes sense. It seems pretty subtle and complicated, and
therefore I'm a little worried that it will be fragile against future
code changes. Someone will think it's a good idea to slightly change
the capset() semantics and only a year later will we realize that the
bounding set is no longer working...
We'll have to be diligent then :-) In truth, the whole model is not
entirely unsubtle.
So this will all have to be very well documented (and tested).
(Actually I notice that capabilities(7) manpage isn't in the libcap
sources. So an update to that is probably long overdue...)
I don't believe it ever was. So far as I can tell this file has had its
own life as part of the 'manpages' package.
This also makes it possible for you to allow pI to have a capability
otherwise banned in cap_bset which is useful with limited role accounts.
Yeah... so the way you'd see this happening, I assume, is that
1. login would keep some capset in pI for user hallyn,
The pam_cap module in the libcap2 tree already does the pI part of this
via libcap (and I intend adding this prctl/cap_bset support in libcap
and that module too).
2. so if /bin/foo had some nonempty fI, hallyn could run
/bin/foo with cap_intersect(pI|fI)?
Yes. The inheritable set is precisely for supporting role-account things
like this, but unlike the superuser concept (any app can be run with
privilege), the application needs to be prepared to wield them - via its
fI bits - before the capabilities are available.
So now the bounding set would place a restriction on what /bin/login in
some container could leave in hallyn's pI.
To be clear, I'm saying that cap_bset will limit what a process can
'add' to the pre-existing pI set, and not what can be 'left in' there.
That is, if pI contains something not present in cap_bset, it will
survive unless some process drops it.
For completeness, without this new check:
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().
it was possible to subvert the bounding set (in your container, but more
generally in any process tree) as follows:
capbound drop cap_net_raw
noraw cp /bin/ping evil-ping
noraw cc evil-shell.c -o evil-shell
since you've not dropped cap_setfcap, the following will work
noraw sudo /sbin/setcap cap_setpcap=pe evil-shell
noraw sudo /sbin/setcap cap_net_raw=ie evil-ping
noraw ./evil-shell
evil-shell uses CAP_SETPCAP to raise pI=CAP_NET_RAW
evil ./evil-ping another-hack-completed.evil.com
Cheers
Andrew
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFHRStSQheEq9QabfIRAqo8AJ9wr+h0bTHgp7iT5fI2lYmuKKa75wCffMsT
Q7y/JN4NuImodhYvm5mvGwY=
=sTdY
-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
