[PATCH] 2.5.41 capget fix

[PATCH] 2.5.41 capget fix

[Chris Wright]

Linus,

Daniel Jacobowitz noticed that sys_capget is not behaving properly when
called with pid of 0.  It is supposed to return current capabilities,
not those of swapper.  Also cleaned up some duplicate code from a merge
error.  Patch is tested, please apply.

thanks,
-chris

--- 2.5.41/kernel/capability.c	Sun Sep 15 12:19:29 2002
+++ 2.5.41-capget/kernel/capability.c	Wed Oct  9 16:31:10 2002
@@ -33,7 +33,7 @@
      int ret = 0;
      pid_t pid;
      __u32 version;
-     task_t *target;
+     task_t *target = current;
      struct __user_cap_data_struct data;
 
      if (get_user(version, &header->version))
@@ -52,21 +52,20 @@
              return -EINVAL;
 
      spin_lock(&task_capability_lock);
-     read_lock(&tasklist_lock); 
 
-     target = find_task_by_pid(pid);
-     if (!target) {
-          ret = -ESRCH;
-          goto out;
+     if (pid && pid != current->pid) {
+	     read_lock(&tasklist_lock); 
+	     target = find_task_by_pid(pid);
+	     read_unlock(&tasklist_lock); 
+	     if (!target) {
+	          ret = -ESRCH;
+	          goto out;
+	     }
      }
 
-     data.permitted = cap_t(target->cap_permitted);
-     data.inheritable = cap_t(target->cap_inheritable); 
-     data.effective = cap_t(target->cap_effective);
      ret = security_ops->capget(target, &data.effective, &data.inheritable, &data.permitted);
 
 out:
-     read_unlock(&tasklist_lock); 
      spin_unlock(&task_capability_lock);
 
      if (!ret && copy_to_user(dataptr, &data, sizeof data))
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: [PATCH] 2.5.41 capget fix

[Linus Torvalds]

On Wed, 9 Oct 2002, Chris Wright wrote:
> 
> Daniel Jacobowitz noticed that sys_capget is not behaving properly when
> called with pid of 0.  It is supposed to return current capabilities,
> not those of swapper.  Also cleaned up some duplicate code from a merge
> error.  Patch is tested, please apply.

This is not correct. You drop the tasklist_lock before you actually set 
read the capabilities, which means that by the time you read them, the 
task you looked up may not be there any more.

		Linus

Re: [PATCH] 2.5.41 capget fix

[Chris Wright]

* Linus Torvalds (torvalds@transmeta.com) wrote:
> On Wed, 9 Oct 2002, Chris Wright wrote:
> > 
> > Daniel Jacobowitz noticed that sys_capget is not behaving properly when
> > called with pid of 0.  It is supposed to return current capabilities,
> > not those of swapper.  Also cleaned up some duplicate code from a merge
> > error.  Patch is tested, please apply.
> 
> This is not correct. You drop the tasklist_lock before you actually set 
> read the capabilities, which means that by the time you read them, the 
> task you looked up may not be there any more.

Doh...feeling dumb...

The patch below fixes my oversight.  The locking is left the way it was,
and just the pid 0 part is fixed as well as the duplicate code removed.
This still applies against bk-curr and I tested it on 2.5.41.

thanks,
-chris

--- 2.5.41/kernel/capability.c	Sun Sep 15 12:19:29 2002
+++ 2.4.41-capget/kernel/capability.c	Thu Oct 10 14:36:29 2002
@@ -33,7 +33,7 @@
      int ret = 0;
      pid_t pid;
      __u32 version;
-     task_t *target;
+     task_t *target = current;
      struct __user_cap_data_struct data;
 
      if (get_user(version, &header->version))
@@ -54,15 +54,14 @@
      spin_lock(&task_capability_lock);
      read_lock(&tasklist_lock); 
 
-     target = find_task_by_pid(pid);
-     if (!target) {
-          ret = -ESRCH;
-          goto out;
+     if (pid && pid != current->pid) {
+	     target = find_task_by_pid(pid);
+	     if (!target) {
+	          ret = -ESRCH;
+	          goto out;
+	     }
      }
 
-     data.permitted = cap_t(target->cap_permitted);
-     data.inheritable = cap_t(target->cap_inheritable); 
-     data.effective = cap_t(target->cap_effective);
      ret = security_ops->capget(target, &data.effective, &data.inheritable, &data.permitted);
 
 out:

Re: [PATCH] 2.5.41 capget fix

[Linus Torvalds]

On Thu, 10 Oct 2002, Chris Wright wrote:
> 
> The patch below fixes my oversight.  The locking is left the way it was,
> and just the pid 0 part is fixed as well as the duplicate code removed.

All right, call me stupid, but twhere is the "duplication" in the code you 
removed?

I see the "security/capability.c" thing, yes, but I also look at
"security/dummy.c", and it appears that at least for that case nobody
would ever initialize the capabilities that we return to user space at
all.

So there's a bug somewhere there, and removing the duplication makes 
things worse (admittedly for a case which isn't enabled in the regular 
kernel, but still..)

So I'd ask you to have patience with me, and send a third patch that gets 
this thing right too.. 

		Linus

[PATCH] sys_capget should use current if the pid argument is 0

[Daniel Jacobowitz]

On Fri, Oct 11, 2002 at 07:58:46PM -0700, Linus Torvalds wrote:
> 
> On Thu, 10 Oct 2002, Chris Wright wrote:
> > 
> > The patch below fixes my oversight.  The locking is left the way it was,
> > and just the pid 0 part is fixed as well as the duplicate code removed.
> 
> All right, call me stupid, but twhere is the "duplication" in the code you 
> removed?
> 
> I see the "security/capability.c" thing, yes, but I also look at
> "security/dummy.c", and it appears that at least for that case nobody
> would ever initialize the capabilities that we return to user space at
> all.
> 
> So there's a bug somewhere there, and removing the duplication makes 
> things worse (admittedly for a case which isn't enabled in the regular 
> kernel, but still..)
> 
> So I'd ask you to have patience with me, and send a third patch that gets 
> this thing right too.. 

Since this is still broken a month later... I don't know what to do
about the "duplication" question, but I'll leave that to Chris.  This
is the uncontroversial portion of Chris's patch; its affect is to
change my zsh shell prompt back to a '%' as I'd expect.

Linus, please apply.

[PATCH] sys_capget should use current if the pid argument is 0

===== kernel/capability.c 1.6 vs edited =====
--- 1.6/kernel/capability.c	Sat Sep 14 09:18:49 2002
+++ edited/kernel/capability.c	Tue Nov 19 16:10:59 2002
@@ -33,7 +33,7 @@
      int ret = 0;
      pid_t pid;
      __u32 version;
-     task_t *target;
+     task_t *target = current;
      struct __user_cap_data_struct data;
 
      if (get_user(version, &header->version))
@@ -54,10 +54,12 @@
      spin_lock(&task_capability_lock);
      read_lock(&tasklist_lock); 
 
-     target = find_task_by_pid(pid);
-     if (!target) {
-          ret = -ESRCH;
-          goto out;
+     if (pid && pid != current->pid) {
+             target = find_task_by_pid(pid);
+             if (!target) {
+                  ret = -ESRCH;
+                  goto out;
+            }
      }
 
      data.permitted = cap_t(target->cap_permitted);

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [PATCH] sys_capget should use current if the pid argument is 0

[Chris Wright]

* Daniel Jacobowitz (dan@debian.org) wrote:
> On Fri, Oct 11, 2002 at 07:58:46PM -0700, Linus Torvalds wrote:
> > 
> > On Thu, 10 Oct 2002, Chris Wright wrote:
> > > 
> > > The patch below fixes my oversight.  The locking is left the way it was,
> > > and just the pid 0 part is fixed as well as the duplicate code removed.
> > 
> > All right, call me stupid, but twhere is the "duplication" in the code you 
> > removed?
> > 
> > I see the "security/capability.c" thing, yes, but I also look at
> > "security/dummy.c", and it appears that at least for that case nobody
> > would ever initialize the capabilities that we return to user space at
> > all.
> > 
> > So there's a bug somewhere there, and removing the duplication makes 
> > things worse (admittedly for a case which isn't enabled in the regular 
> > kernel, but still..)
> > 
> > So I'd ask you to have patience with me, and send a third patch that gets 
> > this thing right too.. 
> 
> Since this is still broken a month later... I don't know what to do
> about the "duplication" question, but I'll leave that to Chris.  This
> is the uncontroversial portion of Chris's patch; its affect is to
> change my zsh shell prompt back to a '%' as I'd expect.

Thanks Daniel.  I've been using the patch below, which differs only
slightly from the one you posted (code style matches the same lookup in
sys_capset).  I'll follow up with the patch that removes the duplicate
code.

[PATCH] sys_capget should use current if the pid argument is 0

===== kernel/capability.c 1.5 vs edited =====
--- 1.5/kernel/capability.c	Sun Sep 15 12:19:29 2002
+++ edited/kernel/capability.c	Tue Nov 19 15:57:15 2002
@@ -54,11 +54,14 @@
      spin_lock(&task_capability_lock);
      read_lock(&tasklist_lock); 
 
-     target = find_task_by_pid(pid);
-     if (!target) {
-          ret = -ESRCH;
-          goto out;
-     }
+     if (pid && pid != current->pid) {
+	     target = find_task_by_pid(pid);
+	     if (!target) {
+	          ret = -ESRCH;
+	          goto out;
+	     }
+     } else
+	     target = current;
 
      data.permitted = cap_t(target->cap_permitted);
      data.inheritable = cap_t(target->cap_inheritable); 

[PATCH] remove duplicated assignment from sys_capget.

[Chris Wright]

* Chris Wright (chris@wirex.com) wrote:
> I'll follow up with the patch that removes the duplicate code.

This patch, relative to the last patch in this thread, removes the
code from cap_sysget that fills out the capability set being returned
to userspace.  The module handles this in a policy specific way.  This
updates the dummy.c module to fill in return data according to superuser
policy, and also disables setting capabilities in superuser policy.

[PATCH] remove duplicated assignment from sys_capget.

===== kernel/capability.c 1.6 vs edited =====
--- 1.6/kernel/capability.c	Tue Nov 19 15:57:15 2002
+++ edited/kernel/capability.c	Tue Nov 19 15:59:38 2002
@@ -63,9 +63,6 @@
      } else
 	     target = current;
 
-     data.permitted = cap_t(target->cap_permitted);
-     data.inheritable = cap_t(target->cap_inheritable); 
-     data.effective = cap_t(target->cap_effective);
      ret = security_ops->capget(target, &data.effective, &data.inheritable, &data.permitted);
 
 out:
===== security/dummy.c 1.4 vs edited =====
--- 1.4/security/dummy.c	Fri Oct 11 14:22:54 2002
+++ edited/security/dummy.c	Tue Nov 19 14:58:11 2002
@@ -27,6 +27,17 @@
 static int dummy_capget (struct task_struct *target, kernel_cap_t * effective,
 			 kernel_cap_t * inheritable, kernel_cap_t * permitted)
 {
+	*effective = *inheritable = *permitted = 0;
+	if (!issecure(SECURE_NOROOT)) {
+		if (target->euid == 0) {
+			*permitted |= (~0 & ~CAP_FS_MASK);
+			*effective |= (~0 & ~CAP_TO_MASK(CAP_SETPCAP) & ~CAP_FS_MASK);
+		}
+		if (target->fsuid == 0) {
+			*permitted |= CAP_FS_MASK;
+			*effective |= CAP_FS_MASK;
+		}
+	}
 	return 0;
 }
 
@@ -35,7 +46,7 @@
 			       kernel_cap_t * inheritable,
 			       kernel_cap_t * permitted)
 {
-	return 0;
+	return -EPERM;
 }
 
 static void dummy_capset_set (struct task_struct *target,