CAP_SYS_PTRACE fails?

Discuss usability issues, general maintenance, and general support issues for a grsecurity-enabled system.

CAP_SYS_PTRACE fails?

Postby cmouse » Sat Dec 27, 2003 8:28 pm

I can't get gdb to debug my programs properly. I dunno why but it seems that ptrace is denied EVEN if the subject has +CAP_SYS_PTRACE.
cmouse
 
Posts: 98
Joined: Tue Dec 17, 2002 10:58 am

Postby cmouse » Tue Dec 30, 2003 11:13 am

Perhaps it would help if I give you my ACL. Kernel has all memory protections turned on. The usual trick of using chpax on the binary to be debugged won't help, since the kernel denies use of ptrace() on the binary.
Here is the ACL I've used for gdb:

/usr/bin/gdb {
+CAP_SYS_PTRACE
/usr/bin/gdb rxi
/home rwx
}

Here is what GDB says:
$ gdb eics
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) break main
Breakpoint 1 at 0x804ab7d: file main.c, line 5.
(gdb) run
Starting program: /home/cmouse/projects/eics/eics
Cannot exec /bin/bash: Permission denied.

Program exited with code 0177.
You can't do that without a process to debug.
(gdb)

Here is what kernel says when trying to debug a binary:
grsec: From 194.100.219.29: denied ptrace of /bin/bash by (gdb:31768) UID(1000) EUID(1000), parent (gdb:32445) UID(1000) EUID(1000)

So any explanations or suggestions on what to do? I really would like to debug software I make. Thank you.
cmouse
 
Posts: 98
Joined: Tue Dec 17, 2002 10:58 am

Postby PaX Team » Tue Dec 30, 2003 2:36 pm

cmouse wrote:Starting program: /home/cmouse/projects/eics/eics
Cannot exec /bin/bash: Permission denied.
do you get that error message because of the denied ptrace or an execve("/bin/bash") rather (you can test the latter by adding exec rights to it in the gdb ACL)?
PaX Team
 
Posts: 2310
Joined: Mon Mar 18, 2002 4:35 pm

Postby cmouse » Wed Dec 31, 2003 4:27 am

Ok. I tested it with following ACL's as well:

/usr/bin/gdb {
+CAP_SYS_PTRACE
/bin/bash rwxt
/usr/bin/gdb rwxti
/home rwxt
}

This creates no errors, but it will cause GDB to hang since it can't modify the running binary.

Next ACL:

/usr/bin/gdb {
+CAP_SYS_PTRACE
/bin/bash rwxt
/usr/bin/gdb rwxti
}

Starting program: /home/cmouse/projects/eics/eics
/bin/bash: line 1: /home/cmouse/projects/eics/eics: Permission denied
/bin/bash: line 1: /home/cmouse/projects/eics/eics: Success

Program exited with code 01.
You can't do that without a process to debug.

grsec: From 194.100.219.29: denied ptrace of /home/cmouse/projects/eics/eics by (bash:798) UID(1000) EUID(1000), parent (gdb:21687) UID(1000) EUID(1000)

So this ACL 'should' work, but it seems to deny any ptrace().

Btw, I'm using Linux 2.4.23 with grsecurity-1.9.13-2.4.23 patch.
cmouse
 
Posts: 98
Joined: Tue Dec 17, 2002 10:58 am

Postby cmouse » Wed Dec 31, 2003 4:30 am

I also tested with following ACL:

/usr/bin/gdb {
+CAP_SYS_PTRACE
/bin/bash rwxti
/usr/bin/gdb rwxti
}

(gdb) run
Starting program: /home/cmouse/projects/eics/eics
/bin/bash: line 1: /home/cmouse/projects/eics/eics: Permission denied
/bin/bash: line 1: /home/cmouse/projects/eics/eics: Success

Program exited with code 01.
You can't do that without a process to debug.

grsec: From 194.100.219.29: denied ptrace of /home/cmouse/projects/eics/eics by (bash:813) UID(1000) EUID(1000), parent (gdb:15720) UID(1000) EUID(1000)
cmouse
 
Posts: 98
Joined: Tue Dec 17, 2002 10:58 am

Postby PaX Team » Wed Dec 31, 2003 5:04 am

cmouse wrote:/usr/bin/gdb {
+CAP_SYS_PTRACE
/bin/bash rwxt
/usr/bin/gdb rwxti
/home rwxt
}

This creates no errors, but it will cause GDB to hang since it can't modify the running binary.
ok, stick to this one and use chpax or the ACL system to remove at least MPROTECT on your targets (the grsec ACL doc has an example for this).
PaX Team
 
Posts: 2310
Joined: Mon Mar 18, 2002 4:35 pm

Postby cmouse » Wed Dec 31, 2003 3:42 pm

:\

$ chpax -v eics

----[ chpax 0.5 : Current flags for eics (pEmrxs) ]----

* Paging based PAGE_EXEC : disabled
* Trampolines : emulated
* mprotect() : not restricted
* mmap() base : not randomized
* ET_EXEC base : not randomized
* Segmentation based PAGE_EXEC : disabled

Was already that when testing... sorry.
cmouse
 
Posts: 98
Joined: Tue Dec 17, 2002 10:58 am

Postby PaX Team » Thu Jan 01, 2004 8:28 am

cmouse wrote:$ chpax -v eics

----[ chpax 0.5 : Current flags for eics (pEmrxs) ]----
i'm wondering where gdb tries to set a breakpoint first. could it be bash itself and hence you'd need to chpax it as well?
PaX Team
 
Posts: 2310
Joined: Mon Mar 18, 2002 4:35 pm

Postby cmouse » Thu Jan 01, 2004 5:44 pm

I did some kernel diggin' and found out that I SHOULD be able to use ptrace() on any process that I own, except if it's denied by 'd' flag.
cmouse
 
Posts: 98
Joined: Tue Dec 17, 2002 10:58 am

Postby cmouse » Thu Jan 01, 2004 5:47 pm

(gdb) run
Starting program: /home/cmouse/projects/eics/eics
Warning:
Cannot insert breakpoint 1.
Error accessing memory address 0x804ab7d: Operation not permitted.
Cannot insert breakpoint -2.
Error accessing memory address 0x4000b650: Operation not permitted.

This came with following ACL:
/usr/bin/gdb {
+CAP_SYS_PTRACE
/bin/bash rwxti
/usr/bin/gdb rwxti
/home rwxt
}

So. I can't get readwrite ptrace().
cmouse
 
Posts: 98
Joined: Tue Dec 17, 2002 10:58 am

Postby cmouse » Thu Jan 01, 2004 5:59 pm

And as usual, solutions will be eventually found when you look hard enough.

/usr/bin/gdb O {
/bin/bash rxi
/usr/bin/gdb rxi
/home rwx
}

(gdb) run
Starting program: /home/cmouse/projects/eics/eics

Breakpoint 1, main () at main.c:5
5 OpenSSL_add_all_ciphers();

Thanks for the help. It did guide me the right way.
cmouse
 
Posts: 98
Joined: Tue Dec 17, 2002 10:58 am


Return to grsecurity support