Messages in this thread | | | From | peeterj@ca ... | Date | Sat, 17 Apr 1999 13:39:34 -0400 | Subject | Re: using capabilities to allow debug of suid-root programs (ptrace not allowed even after dropping privs) |
| |
Thanks Andrew,
I had tried something similar (I was using libcap directly though) and it wasn't working because of stupid directory permission problems (when I got the same error with your wrapper I clued in).
Now, I modified the program you sent me slightly, so that I can use it to run gdb, or ddd as specified on the command line, but when using this the program capabilities aren't restricted to ptrace!
---------------------------- #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <errno.h> #include <string.h>
/* make this program setuid root */
int main(int argc, char **argv) { int i; char ** new_args = (char **)calloc(argc+3, sizeof(char **));
if (new_args == NULL) { fprintf(stderr, "no memory\n"); exit(1); }
setuid(geteuid());
new_args[0] = "/sbin/execcap"; new_args[1] = "execcap"; new_args[2] = "cap_sys_ptrace=i";
for (i=0; ++i<argc; ) { new_args[2+i] = argv[i]; }
execvp(new_args[0], new_args+1);
fprintf(stderr, "Unable to execute command: %s\n", strerror(errno)); for (i=0; new_args[i]; ++i) { printf(" %s", new_args[i]); } printf("\n"); return 1; } ----------------------------
compiling this and setting it suid-root allows me to do other root-capable things that aren't ptrace (creation and deletion of a file in /). /proc/<pid>/status shows only one bit (presumably CAP_SYS_PTRACE) set in the capability sets, so it looks like that part of the program is working as it is supposed to.
CapInh: 0000000000080000 CapPrm: 0000000000080000 CapEff: 0000000000080000
[root@openfire cap]# make debugwrap mode cc -g -Wall debugwrap.c -o debugwrap chown root tcap debugwrap t chmod u+s tcap debugwrap t
[pjoot@openfire cap]$ ./debugwrap touch /blah [pjoot@openfire cap]$ ls -l /blah -rw-r--r-- 1 root build 0 Apr 17 13:24 /blah [pjoot@openfire cap]$ ./debugwrap rm /blah [pjoot@openfire cap]$ ls -l /blah ls: /blah: No such file or directory
This seems no different then a plain old suid root program. I tried setreuid(getuid(), getuid()) before the exec (and after the cap_set_proc), but this clears other capabilities at the same time. I thought that the whole idea of this capability stuff is so that the entire set of root capabilities isn't explicitly inherited, but this appears to be what is happening? Is the problem that ext2, or some other part of the kernel is just not respecting the capabilities flags properly, and is unconditionally doing the open which creates the file /blah when it sees the uid is 0?
Peeter
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |