Hello Jake,

I created this patch to make the Capsicumization experience less intimidating for inexperienced developers. Both David and Mariusz may not be the target audience for this change

I created this patch to make the Capsicumization experience less intimidating for inexperienced developers. Both David and Mariusz may not be the target audience for this change because they already know how to extract the information that the tracing provides. Developers that are unfamiliar with Capsicum's semantics could use this tracing mode to easily determine why their program is not working in capability mode. I think it provides a solid starting point so new developers don't get lost and discouraged.

It's doable in principle, but in practice dtrace's inability to resolve backtraces in the face of fork/exec makes it mostly unusable

In D40676#958341, @theraven wrote:

Are these events exposed to DTrace? When sandboxing, the thing I really want is a stack trace in userspace at the point where the violation happened. If so, it would be great to include a script that logged them. Ideally with an option of an explicit start marker so you can put in a fake cap_enter and be told what you still need to fix.

Are these events exposed to DTrace? When sandboxing, the thing I really want is a stack trace in userspace at the point where the violation happened. If so, it would be great to include a script that logged them. Ideally with an option of an explicit start marker so you can put in a fake cap_enter and be told what you still need to fix.

Ah, ok I thought it was printed by default.
Then I don't think I have any complaints through the idea.

In D40676#958254, @oshogbo wrote:

If I understand correctly, for application like:

localtime();
open();
cap_enter()
openat()

The first two operations will always cause ktrace to report insufficient capabilities. Which is a false-postive statement, and will be misleading for "normal" users.

If I understand correctly, for application like:

localtime();
open();
cap_enter()
openat()

In D40676#958215, @oshogbo wrote:

To summarize the patch very briefly, this lets you ktrace an application that does not run in capability mode, and ktrace will log all events which would have triggered a Capsicum violation.

I haven't looked into the code, to be honest. However, I don't see a real application for this approach, or maybe I misread how this is supposed to work.
Is this a tool for improving debugging sandboxed applications or sandboxing new applications?

Again, maybe I just need some more context to understand the reasoning behind this change.

To summarize the patch very briefly, this lets you ktrace an application that does not run in capability mode, and ktrace will log all events which would have triggered a Capsicum violation.

In D40676#958207, @theraven wrote:

To summarize the patch very briefly, this lets you ktrace an application that does not run in capability mode, and ktrace will log all events which would have triggered a Capsicum violation.

So this traces the system calls that are not on the allowed-in-cap-mode list?

To summarize the patch very briefly, this lets you ktrace an application that does not run in capability mode, and ktrace will log all events which would have triggered a Capsicum violation.

Overall this looks good to me. I wonder if @emaste, @oshogbo or @theraven have any thoughts on it? To summarize the patch very briefly, this lets you ktrace an application that does not run in capability mode, and ktrace will log all events which would have triggered a Capsicum violation.

Fix formatting issue in license text

Use cap_svflags instead of cap_flags when determining kernel ABI with syscallabi().

Change NI_LCF_STRICTRELATIVE to NI_LCF_STRICTREL where applicable.

Use AT_STDIN instead of STDIN_FILENO to force read from stdin in readpassphraseat().

The diff looks good.

• cdfd is no longer a global variable. Instead, it is passed locally per function call.
• Open _PATH_TTY, limit its rights, and use readpassphraseat() instead of readpassphrase().
• Limit stdio instead of just stdin.

In D39009#889101, @jfree wrote:

In D39009#888934, @markj wrote:

This looks good! Three comments:

• I don't like that cdfd is a global variable. I'd rather see it plumbed everywhere that we pass a path, even though that's kind of onerous.

I am curious why cdfd would be better suited as a local variable? Namespace pollution doesn't seem to be an issue in a small userspace program and passing it would just add one extra argument to the stack for every function call. Is the idea to isolate its scope?

In D39009#888934, @markj wrote:

This looks good! Three comments:

• I don't like that cdfd is a global variable. I'd rather see it plumbed everywhere that we pass a path, even though that's kind of onerous.

This looks good! Three comments:

• I don't like that cdfd is a global variable. I'd rather see it plumbed everywhere that we pass a path, even though that's kind of onerous.
• I think readpassphrase() does not quite work in capability mode. See the implementation in lib/libc/gen/readpassphrase.c - it opens /dev/tty. It does have a fallback path, but I'm not sure how well that works. Could you please try writing a little standalone program that enters capability mode and tries to use readpassphrase()? Depending on how that goes, we may want to add a new variant of that function which takes fds from the caller.
• Have you tried testing with kern.trap_enotcap set to 1? That'll help catch any system calls that might be silently failing because we're in capability mode.

Open current directory, enter capability mode, then use *at() syscalls to extract archive files.

Alter function names and comments for clarity

Rebased

In D38860#887537, @rew wrote:

In D38860#887381, @rew wrote:

https://reviews.freebsd.org/D38858 also needs to be addressed before this patch is committed.

I've dropped my request for changes in D38858 - there's nothing blocking this review from being landed.