Fix filesystem capability support

In linux-2.6.24-rc1, security/commoncap.c:cap_inh_is_capped() was
introduced. It has the exact reverse of its intended behavior. This
led to an unintended privilege esculation involving a process'
inheritable capability set.

To be exposed to this bug, you need to have Filesystem Capabilities
enabled and in use. That is:

- CONFIG_SECURITY_FILE_CAPABILITIES must be defined for the buggy code
  to be compiled in.

- You also need to have files on your system marked with fI bits raised.

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

Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@akpm@linux-foundation.org>

1 files changed, 10 insertions, 3 deletions

diff --git a/security/commoncap.c b/security/commoncap.c
index 5bc1895f3f9c..ea61bc73f6d3 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -59,6 +59,12 @@ int cap_netlink_recv(struct sk_buff *skb, int cap)
 
 EXPORT_SYMBOL(cap_netlink_recv);
 
+/*
+ * NOTE WELL: cap_capable() cannot be used like the kernel's capable()
+ * function.  That is, it has the reverse semantics: cap_capable()
+ * returns 0 when a task has a capability, but the kernel's capable()
+ * returns 1 for this case.
+ */
 int cap_capable (struct task_struct *tsk, int cap)
 {
         /* Derived from include/linux/sched.h:capable. */
@@ -107,10 +113,11 @@ static inline int cap_block_setpcap(struct task_struct *target)
 static inline int cap_inh_is_capped(void)
 {
         /*
-         * return 1 if changes to the inheritable set are limited
-         * to the old permitted set.
+         * Return 1 if changes to the inheritable set are limited
+         * to the old permitted set. That is, if the current task
+         * does *not* possess the CAP_SETPCAP capability.
          */
-        return !cap_capable(current, CAP_SETPCAP);
+        return (cap_capable(current, CAP_SETPCAP) != 0);
 }
 
 #else /* ie., ndef CONFIG_SECURITY_FILE_CAPABILITIES */