In D58164#1333865, @kib wrote:

This is not finished, I need some help with the build system.

First, the reroot_seed binary should not be installed. I do not see how to specify this with the bsd.prog.mk.

Are the tests all passing now?

I don't think this patch is a good idea. It adds a bunch of complexity and state to a security layer in order to support a debugging feature, as I understand it.

In D58094#1332534, @kib wrote:

In D58094#1332492, @markj wrote:

Even if the debugee is also in capability mode, the debugger would still potentially be able to obtain capabilities it doesn't already have, violating the sandbox rules.

For this, the debugger needs to get the procdesc to the target with enough cap allowed. If something provided it, then it was the decision.

In D58094#1332531, @kevans wrote:

In D58094#1332492, @markj wrote:

In D58094#1332300, @kevans wrote:

Re: obtaining pdfd, in an lsan context we don't really have any choice- we're effectively running in a hostile environment, and we may not get the chance to execute anything privileged (because our image may infact even be exec'd that way). We allow getpid() in capability mode, though, so I didn't really see a problem with allowing pdopenpid for the process itself.

Sorry, what does LSAN have to do with capability mode?

There is no relation, except that LSAN cannot work if a program is in capability mode because it needs to momentarily freeze the program and collect current state about it to detect leaks. Right now, only ptrace(2) has the right facilities for this (it uses just the set that I enumerated above). Given your other point about even the target being in capability mode may be unsafe, it may be the case that we need something like PT_TRACE_ME to bless the relationship or declare it safe or something? I don't think you necessarily want to set the precedence that a child is able to trace its parent in the normal case, since the parent may have dropped resources after forking.

In D58094#1332300, @kevans wrote:

In D58094#1332294, @kib wrote:

In D58094#1332276, @markj wrote:

Why not just use ptrace(PT_ATTACH, pdgetpid(), ...)? I can see some argument for PT_ATTACH_PD if you are planning to make ptrace() available in capability mode.

Exactly what Kyle said above.

In D58094#1332272, @kevans wrote:

Nice, this seems reasonable to me. I have a proposal that I'm gonig to send to a list, but effectively, I'd like to do a few things in this area:

• Add a convenience pdopenpid(0, ...) -> similar to what we do with setpgrp/setpggid, special-case 0 to allow self-pdopenpid without a getpid() call
• Mark pdopenpid(2) CAPENABLED, allow it in capability mode only for self-requests
• Mark ptrace(2) CAPENABLED, only allow: PT_ATTACH_PD, PT_DETACH, PT_GETNUMLWPS, PT_GETLWPLIST, PT_GETREGS

PT_VM_TIMESTAMP, TP_VM_ENTRY, PT_GETREGSET, PT_GET_SC_ARGS, PT_GET_SC_RET, and MD options.

But I really thought that if you have the pfd with the capability, then you can debug the target as you want. pdopenpid() should be not allowed lightly for capsicum, but you could get the pfd by other means, e.g. by passing it from some fully privileged wrapper.

I think my concern is that you can easily exfiltrate or manage resources from the global namespace if you can get ahold of a pdfd for a process that isn't also in capability mode. Even without remote syscall capability directly, you can still drive arbitrary execution with proper stepping and reg swapping. We probably want to be pretty conservative in what we allow to limit the possible shenanigans.

Why not just use ptrace(PT_ATTACH, pdgetpid(), ...)? I can see some argument for PT_ATTACH_PD if you are planning to make ptrace() available in capability mode.

Apply kib's suggestion

I have run the tests manually, I'm still not quite sure how to run them through FreeBSD's build system.

The division of responsibilities between prison remove methods, VNET SYSUNINITs and MOD_UNLOAD handlers is super hard to understand...

Re-check that the child is sleeping.

In D58023#1331065, @kib wrote:

Do we want some test to ensure that pdopenpid() has no effect on the target? I mean, ptrace(PT_ATTACH) might cause spurious wakeups (partially mitigated now).

Address review feedback, add procdesc_no_wakeup