kern: add p_canopen() The function defines the policy for allowing to open a pid. pdptrace(2): allow debugging in capability mode The pdopenpid(2) and pdptrace(2) syscalls are allowed in capability mode. Add the chicken switch security.bsd.ptrace_in_cap_mode, which disables them without reboot, if needed. For ptrace(2), the PT_ATTACH by pid request is unconditionally disabled in the cap mode. All other requests are enabled, but that would only work if we already have the process reparented to the caller as the debugger. The ptrace(PT_ATTACH | PT_PROCDESC) call is allowed, The descriptor passed to PT_ATTACH must have the CAP_PTRACE capability enabled. This capability is not enabled by default by pdfork()/pdopenpid(), and the calls do not return a procdesc suitable for debugging. The opening code must prepare for debugging in advance by passing the PD_PTRACE_CAP flag to pdfork()/pdopenpid(). In addition, the pdopenpid() is allowed to open processes which are either direct children of the caller, or are debuggees already attached to the calling process. This is reasonable because we could have controlled the child on fork anyway. The procdesc-less debuggee can legitimately appear due to ptrace FOLLOW-FORK mode. For ptrace(2), allow PT_CONTINUE and PT_GET_CHILDREN for current process in cap mode as well. ptrace.2/pdfork.2: document PD_PTRACE_CAP, and ptrace(2) in cap mode
Details
Details
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
| lib/libsys/pdfork.2 | ||
|---|---|---|
| 180 | ||
| 184 | ||
| 186 | I think this would be clear enough as a sentence, instead of a list. | |
| 191 | I think it is probably confusing to say "real parent" here, that really kernel terminology. For userspace, IMO we should say "parent" or "debugger". | |
| 192 | or, "with the .Dv PTRACE_FORK flag set." | |
| 463 | ||
| sys/kern/kern_prot.c | ||
| 2320 | Indentation is wrong here. | |
| sys/kern/sys_process.c | ||
| 77 | Now that CAP_PTRACE is clear by default, I am not sure if this chicken switch is really needed. | |
| sys/kern/sys_process.c | ||
|---|---|---|
| 77 | I prefer to keep it, just in case some PD_PTRACE_CAP consumer appears to be flaky. For instance, it might leak CAP_PTRACE capable fd by not setting PD_CLOEXEC and then execing something. The cost is small. | |