Problem with GDB

[cmouse]

I'm using grsec-2.0 ACL system and I have the following ACL in default role. Why does it not allow it to ptrace processes I start in my home directory. Claims that it is not allowed to ptrace them.

subject /usr/bin/gdb Or
/usr/bin h
/bin h
/usr/sbin h
/sbin h
/usr/bin/gdb rxi
/bin/bash rxi

Error in syslog
grsec: From 194.100.219.29: denied ptrace of /home/cmouse/projects/turing/turing(turing:17324) by /usr/bin/gdb[gdb:27973] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:8422] uid/euid:1000/1000 gid/egid:1000/1000

Error in GDB

This GDB was configured as "i686-pc-linux-gnu"...
(gdb) break main
Breakpoint 1 at 0x8048d1e: file turing.c, line 229.
(gdb) run
Starting program: /home/cmouse/projects/turing/turing
Couldn't get registers: Operation not permitted.

$ strace ./turing
execve("./turing", ["./turing"], [/* 19 vars */]) = 0
trace: ptrace(PTRACE_SYSCALL, ...): Operation not permitted

Any help would be greatly appreciated

[spender]

I'd need to see the rest of your policy. I've tested here to make sure that ptrace is working correctly in the cases of strace ./blah and gdb ./blah, both with and without adding "Or" to the subject mode. Remember that r is only needed if you're attaching to pids that already exist, and O is only needed if you're ptracing something with a different subject (I would recommend not using that flag, and if you do, restrict tightly what files can be executed).

-Brad

[cmouse]

Uhm, here is the default policy + entire subject policy for GDB

role default G
role_transitions admin
subject /
/ r
/command h
/service h
/.journal h
/home/.journal h
/www/.journal h
/opt rx
/opt/orion rwxcd
/opt/snmp h
/opt/snmp/sbin/snmpd rx
/home rwxcd
/mnt h
/dev
/dev/urandom r
/dev/random r
/dev/initctl h
/dev/zero rw
/dev/input rw
/dev/psaux rw
/dev/null rw
/dev/tty? rw
/dev/console rw
/dev/tty rw
/dev/pts rw
/dev/ptmx rw
/dev/dsp h
/dev/mixer h
/dev/fd? h
/dev/cdrom r
/dev/mem h
/dev/kmem h
/dev/port h
/dev/log hs
/dev/grsec h
/usr/sbin/netstat h
/bin rx
/sbin rx
/sbin/iptables h
/lib rx
/usr rx
/usr/lib/gconv/gconv-modules.cache rwc
/etc rx
/etc/rc.d h
/etc/syslog-ng h
/etc/ssh h
/etc/ssh/ssh_config r
/etc/sudoers h
/etc/eics h
/etc/crontab h
/var/lib/eics h
/proc rwx
/proc/kcore h
/proc/sys r
/root r
/root/.bash_history rw
/root/.mysql_history rw
/tmp rwcd
/tmp/.cpan h
/var rx
/var/lock/subsys rwc
/var/apache2 r
/var/mysql h
/var/postgres h
/var/tmp rwcd
/var/log r
/var/log/php.log rw
/var/log/messages* h
/var/log/auth.log* h
/var/log/kern.log* h
/var/log/debug.log* h
/var/spool/cron h
/var/spool/exim h
/var/cvs h
/var/run/utmp rs
/var/mail rwc
/boot h
/www rwxcd
/etc/grsec h
/opt/j2sdk1.4.2_02 rx
/opt/ircd h
/opt/ircd/asuka?/bin/ircd x
-CAP_SYS_TTY_CONFIG
-CAP_LINUX_IMMUTABLE
-CAP_NET_RAW
-CAP_MKNOD
-CAP_SYS_ADMIN
-CAP_SYS_RAWIO
-CAP_SYS_MODULE
-CAP_SYS_PTRACE
-CAP_NET_ADMIN
-CAP_NET_BIND_SERVICE
-CAP_SYS_CHROOT
-CAP_SYS_BOOT

subject /usr/bin/gdb Or
/usr/bin h
/bin h
/usr/sbin h
/sbin h
/usr/bin/gdb rxi
/bin/bash rxi

That's all.

[spender]

I still can't duplicate your problem. Can you try using grsecurity 2.0.1 that is in CVS (or for 2.6.7 in http://grsecurity.net/~spender) and the CVS of gradm2?

-Brad

[cmouse]

Can't really.. It would require booting etc..

Well, I'll just try to fix it myself... thanks

[cmouse]

Would help if you could tell me what reasons are cause of ptrace denied. I'm not that good at digging it out myself...

[cmouse]

Heh, got it fixed =)
Dunno _why_ it must be done like this, but it seems that it is the only possible way:

subject /usr/bin/gdb O
/home rwxicd
/bin rxp
/sbin rxp
/usr/bin rxp
/usr/sbin rxp
/bin/bash rxi

This is the final ACL I came up with. Should prevent ptracing the wrong places...

[cmouse]

It seems that it no longer works. For some reason when I altered the ACL a bit, it decided to stop working again. This time it denies ptrace of /bin/bash, instead of turing.

As I cannot fully understand why the ACL system decides to deny ptrace for something I cannot assess why it does this. For all I can see, it seems to be rather random in allowing access.