1. Make the system secure by default.
The problem with most security systems is NO ONE turns them on. NO ONE increases the security of their system.
Now while these are exaggerations, I would bet you that 99 % of SELinux users never turn on confined users, or disable the unconfined module . There are large numbers of people who run SELinux in permissive mode or even disabled. If we shipped Fedora and RHEL with SELinux disabled, I would bet the number of people who would enable it would be infinitesimally small. So when I add a feature, I always think about how it would help the vast majority of people. Will this boolean make my Wife's computer more secure.
2. Keep the unconfined domain unconfined...
Read the blog for why uses expect things to just work, especially from their logged in accounts, especially if they are the admin.
Should deny_ptrace be on by default????
Well deny_ptrace actually confines the unconfined domain, so it conflicts with #2, but if I don't turn it on, for the most part people will not take advantage. Most users would not see the benefit. Right now I am going to turn it on by default (Of course I reserve the right to change my mind, or be beaten into submission.) Any person who wants to disable it permanently can execute.
# setsebool -P deny_ptrace 0
Programmers and system admins if you get a "permission denied" or "Operation not supported" error with ptrace, strace or gdb, it is SELinux causing the problem, and if you need to debug a problem, you can turn the boolean on temporarily.
# setsebool deny_ptrace 0
And do your thing.
Since sysadmins and programmers understand Linux best, it would be easier for them to toggle the security feature.
Now some questions about this feature.
What happened to allow_ptrace boolean in RHEL versions and older Fedora's?
I originally thought about extending allow_ptrace, but I thought I had better just create a new boolean and remove the old.
allow_ptrace only effected confined users. But since hardly anyone used confined users, I thought I needed a better way to describe the feature, and change its name. I have removed allow_ptrace and now deny_ptrace will remove all ptrace, sys_ptrace that I know about from the system.
Does deny_ptrace guarantee no domains on my system can ptrace another domain?
If you load a custom policy with an "allow XYZ self:process ptrace", this boolean will not effect it. So it only effects actually policy shipped by Fedora or Red Hat.
deny_ptrace does not effect permissive domains, or permissive mode (obviously), so if you want to make sure no processes can execute ptrace, you need to disable permissive domains.
After you turn on the deny_ptrace boolean, you can check if any domains are still able to ptrace by executing
# sesearch -A -C -p ptrace,sys_ptrace | grep -v ^D