[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080305140624.GA9128@sergelap.austin.ibm.com>
Date: Wed, 5 Mar 2008 08:06:24 -0600
From: "Serge E. Hallyn" <serue@...ibm.com>
To: Jiri Slaby <jirislaby@...il.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org,
"Andrew G. Morgan" <morgan@...nel.org>,
Serge Hallyn <serue@...ibm.com>,
James Morris <jmorris@...ei.org>,
Stephen Smalley <sds@...ho.nsa.gov>,
Paul Moore <paul.moore@...com>
Subject: Re: prctl(0x8) -> EINVAL [Was: 2.6.25-rc3-mm1]
Quoting Jiri Slaby (jirislaby@...il.com):
> On 03/04/2008 10:19 AM, Andrew Morton wrote:
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc3/2.6.25-rc3-mm1/
>> +capabilities-implement-per-process-securebits.patch
>
> This probably causes userspace damage:
>
> dbus:
> prctl(0x8, 0x1, 0, 0, 0) = -1 EINVAL (Invalid argument)
>
> named:
> named: -u with Linux threads not supported: requires kernel support for
> prctl(PR_SET_KEEPCAPS)
> prctl(0x8, 0x1, 0, 0, 0) = -1 EINVAL (Invalid argument)
>
> ntpd:
> prctl(0x8, 0x1, 0xffffffffffffffa8, 0x1, 0) = -1 EINVAL (Invalid argument)
> prctl(0x8, 0x1, 0, 0, 0) = -1 EINVAL (Invalid argument)
>
> $ grep CONFIG_SECURITY .config
> # CONFIG_SECURITY is not set
> # CONFIG_SECURITY_FILE_CAPABILITIES is not set
Thanks, Jiri. Does the following patch work for you?
This patch address the !CONFIG_SECURITY case, but not the case of
using the dummy LSM. The default these days is to have capabilities
compiled in no matter what, but it is still possible to have
CONFIG_SECURITY=y and CONFIG_SECURITY_CAPABILITIES=n, in which
case prctl(0x8) will return -EINVAL. Do we want dummy to call
cap_prctl() as well, or are we ok with userspace getting -EINVAL
given that there are in fact no capabilities at that point and
the userspace code is clearly expecting them?
thanks,
-serge
>From 4a66f19580489a3ac84f0a145e4585c09e65c88e Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn <serue@...ibm.com>
Date: Wed, 5 Mar 2008 06:02:32 -0800
Subject: [PATCH 1/1] capabilities: use cap_task_prctl when !CONFIG_SECURITY
capabilities-implement-per-process-securebits.patch introduced
cap_task_prctl() and moved the handling of capability-related
prctl into it. So when !CONFIG_SECURITY, the default
security_task_prctl() needs to call cap_task_prctl() the way
other default hooks call capability helpers when they exist.
This fixes a slew of userspace breakages when
CONFIG_SECURITY=n.
Signed-off-by: Serge E. Hallyn <serue@...ibm.com>
---
include/linux/security.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/security.h b/include/linux/security.h
index 83763b0..861d6da 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -2228,7 +2228,7 @@ static inline int security_task_prctl (int option, unsigned long arg2,
unsigned long arg4,
unsigned long arg5, long *rc_p)
{
- return 0;
+ return cap_task_prctl(option, arg2, arg3, arg3, arg5, rc_p);
}
static inline void security_task_reparent_to_init (struct task_struct *p)
--
1.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists