Ah, vol is neutralized because of that mixer #36. It defaults to ctl == 0 from the struct being zero-init, so we don't create the synthetic vol parent from the pcm feature unit. I don't have enough hardware available to feel confident about poking that hornet's nest.

Writing a test for this seems to be a little harder than I anticipated, but I'm also wondering now if deleting the knotes was infact the right thing to do. From revoke(2):

I'll look at adding a test for this scenario, and will take a closer look at this in a few hours

Sigh, I typo'ed "Differential". This has landed now.

LGTM, and ack for the core@ add

In D58597#1344902, @bms wrote:

This is directly in the line of fire of my GSoC student's MPLS work.

This looks like what I've done in D57353 already, except with the assignment to buf moved into the conditional?

In D58486#1341966, @des wrote:

I suspect I need approval from portmgr for this since @bapt is away

In D58187#1338218, @ivy wrote:

this might be a good time to move this to the FreeBSD-efi-tools package. it's probably a bug/oversight that it isn't already there.

Whoops, thanks!

In D51865#1334998, @aokblast wrote:

In D51865#1334521, @kevans wrote:

In D51865#1334517, @adrian wrote:

hi!

So why are a whole lot of functions getting an fd added to them?

Do the FDs change during the runtime of the tool? Or are they something that could be set
once during some init phase (maybe in a new function which would call cap_enter, rather than
the owner having to call it) and then pulled out of some the libusb backend state?

IMO we really shouldn't have libraries entering capablity mode- libusb may be just one of many, and setting a precedence like that where some will insist on entering the sandbox is bound to end up with some really annoying circumstances.

I can somehow agree with you. But how can we integrate to bhyve without this as bhyve is capsicumized by default? We can turn off temporary but it adds complexity on bhyve.

Whack the remaining moles, fix OptionalObsoleteFiles to also remove the example

In D51865#1334517, @adrian wrote:

hi!

So why are a whole lot of functions getting an fd added to them?

Do the FDs change during the runtime of the tool? Or are they something that could be set
once during some init phase (maybe in a new function which would call cap_enter, rather than
the owner having to call it) and then pulled out of some the libusb backend state?

In D58152#1333589, @aokblast wrote:

In D58152#1333581, @kevans wrote:

Yes, I think @kib was at least mildly concerned when I raised the thought of doing the same, and we decided it was reasonably fine to just bypass the locks because we do dl_iterate_phdr, rfork (vfork) inside the handler, then ptrace the parent. The thread that holds the relevanr locks is suspended in rfork and safely not racing against what we do in the child.

In D58152#1333577, @aokblast wrote:

In D58152#1333568, @kevans wrote:

In D58152#1333559, @kib wrote:

You do understand, that the change is only changes something for the statically linked binaries?

We had already implemented a workaround in rtld, _dl_iterate_phdr_locked iirc. I'm not sure offhand why that wasn't sufficient here, I might need to re-check which lsan drop I sent to @aokblast

Yes, I see the comment from your brach and see both glibc and NetBSD (although very strange in their implemetation) has recursive dl_phdr_info_lock lock.

In D58152#1333559, @kib wrote:

You do understand, that the change is only changes something for the statically linked binaries?

In D58094#1332688, @markj wrote:

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.

Sanitizers and debuggers don't work properly with ASLR, so they just turn off ASLR. Why isn't that the approach here?

In D58094#1332550, @markj wrote:

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.

... or a sandbox escape bug, if someone forgot to limit rights on the procdesc. There is at least one example in the tree. In particular, this is not a decision made by any existing code, since currently a process descriptor does not give you access to the target process' capabilities.

In D58094#1332543, @kevans wrote:

In D58094#1332533, @markj wrote:

Given that LSAN is a testing tool, why do we care about having it work properly in capability mode at all? The sanitizer runtime could intercept cap_enter()/caph_enter() and prevent the target process from entering a sandbox when running under LSAN.

Another fair point- from my perspective, we probably don't particularly care about it working properly in capability mode, but we should care about the fact that capability mode would causes us to lose this incredibly useful functionality.

That can be solved in the majority of capsicumized things today by intercepting cap_enter, as you note- that doesn't help if an instrumented program was exec'd already in a sandbox by an uninstrumented parent, but to my knowledge we don't really have any case like that in base. I don't think "disabling capsicum on a larger scale if you want to use lsan" (the logical next step to address the last case) is a great approach if we can find a way to make it work safely in that context.

I suppose so, but extending the kernel to support this rather esoteric case, and in so doing increasing the attack surface available to any sandboxed process owning a procdesc with CAP_PTRACE_ATTACH, seems like a dubious tradeoff...

In D58094#1332533, @markj wrote:

Given that LSAN is a testing tool, why do we care about having it work properly in capability mode at all? The sanitizer runtime could intercept cap_enter()/caph_enter() and prevent the target process from entering a sandbox when running under LSAN.

In D58094#1332492, @markj wrote:

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.

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.