Setting security.bsd.unprivileged_proc_debug=0 by default.
Implementing PaX NOEXEC and enforcing it across the ptrace boundary.
Hardening [lin]procfs to prevent tampering with the process address space and registers through modifying key files in /proc/[pid]
Hardening [lin]procfs with regards to ptrace may cause you do go “huh? what?” linprocfs and procfs use the ptrace functions behind-the-scenes. procfs isn’t used much on FreeBSD, anyways, but we might as well plug the same types of holes while hardening ptrace itself.
To me, the architecture of ptrace/proc/linprocfs makes it tricky to secure a system. It’s probably not easy to do better than Linux in this area. Have you considered alternative ways of offering process debugging that don’t involve ptrace?
I prefer DTrace, but that, too, has its issues. It’s still possible to modify some data with DTrace, but it is a bit more limited in that respect than ptrace. I’m unsure one could port libhijack to using dtrace as a backend and keep full functionality.
Does HardenedBSD prevent ptrace?
We’ve hardened ptrace by:
Hardening [lin]procfs with regards to ptrace may cause you do go “huh? what?” linprocfs and procfs use the ptrace functions behind-the-scenes. procfs isn’t used much on FreeBSD, anyways, but we might as well plug the same types of holes while hardening ptrace itself.
To me, the architecture of ptrace/proc/linprocfs makes it tricky to secure a system. It’s probably not easy to do better than Linux in this area. Have you considered alternative ways of offering process debugging that don’t involve ptrace?
I prefer DTrace, but that, too, has its issues. It’s still possible to modify some data with DTrace, but it is a bit more limited in that respect than ptrace. I’m unsure one could port libhijack to using dtrace as a backend and keep full functionality.