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/