Hi people
This is what i understand from the grsecurity implementation .
With grsecurity enabled , the only way of getting gdb to debug a process is to disable restrictions using chpax/paxctl.


Most of the processess that run on my customised linux kernel needs to be debugged and at the same time needs grsecurity protection .

I have two problems staring out of this situation .
1]chpax does not disable restrictions run time . If i want to do remote debugging of process i dont want to kill the process .
Is there an alternative to killing the process ,running chpax on it and then debugging the process ?
What are the consquences or design constraints
of having to disable/enable grsec features run time using chpax?

2] If i use chpax on the binaries before i start the process , then binaries like sshd and xinetd will run unprotected defeating the very purpose of grsec .
[chpax -s binary] disables "segment exec " effectively exposing stack code execution via buffer overflow .

If I want to do remote debugging of process I dont want to kill the process. Is there an alternative to killing the process, running chpax on it and then debugging the process?
Check if the ACL example at http://www.grsecurity.net/gracldoc.h...gs_and_caveats under "PaX flags and caveats" is something you could use.


What are the consquences or design constraints of having to disable/enable grsec features run time using chpax?
Design constraints I don't know. Please ask the PAX team.