- Record *namei* violations instead of vfs. Slight wording change for clarity.
- Rebase on main after several months
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Sun, Mar 10
- Rename all instances of CAPFAIL_VFS to CAPFAIL_NAMEI
- Rebase on main after several months
- Address Mark's comments
- Rebase on main after several months
Jan 18 2024
Jan 9 2024
Replace all instances of "AT_FDCWD" with "<AT_FDCWD>" when reporting a violation via ktrcapfail().
In D40677#988214, @markj wrote:I would frown at that. :) It introduces hidden control flow which makes it hard to see quickly what a function does.
Consider the common case where a function allocates some memory and is supposed to free it before returning: if I'm reviewing the code and want to verify it behaves properly with respect to that free() call, it's much easier to check if I just have to look for the "return" keyword in the function.
Once in a while it's handy, but it should be avoided if possible.
Jan 8 2024
In D40677#988077, @jfree wrote:Actually, scratch that. I just understood your comment and this is a better solution.
As a side note though... Is returning in macros usually frowned upon?
Jan 7 2024
Actually, scratch that. I just understood your comment and this is a better solution.
It feels wrong to return inside of a macro, but I did not see any comments about it in style(9). This seems to be the solution that is most elegant in minimizing code duplication. Let me know your thoughts.
Oct 6 2023
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
Oct 5 2023
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.
Oct 4 2023
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.
Sep 29 2023
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.
Sep 28 2023
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.
Jul 28 2023
Fix formatting issue in license text
Jun 20 2023
Use cap_svflags instead of cap_flags when determining kernel ABI with syscallabi().
Change NI_LCF_STRICTRELATIVE to NI_LCF_STRICTREL where applicable.
Apr 28 2023
Apr 26 2023
Mar 30 2023
Use AT_STDIN instead of STDIN_FILENO to force read from stdin in readpassphraseat().
Mar 27 2023
Mar 21 2023
The diff looks good.
Mar 19 2023
- 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.
Mar 13 2023
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.
Mar 11 2023
Open current directory, enter capability mode, then use *at() syscalls to extract archive files.
Mar 10 2023
Mar 9 2023
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.
Mar 8 2023
In D38860#887381, @rew wrote:https://reviews.freebsd.org/D38858 also needs to be addressed before this patch is committed.
In D38860#887339, @markj wrote:Looks like this patch needs to be rebased.
Looks like this patch needs to be rebased.
Mar 3 2023
Moved casper dependency to lib9p.
Added revert commit 966026246e62769f3bcd8247a47fe0f4f0433aba
Mar 2 2023
Feb 4 2023
Jun 5 2021
Apr 6 2021
LGTM.
Do you have commit bit or should I commit this?
Mar 26 2021
@oshogbo okay to commit?
Feb 2 2021
Feb 1 2021
Thanks, I'll see if I can chase this down later. My commit bit lapsed, please can you land it?
Ok, go ahead with the proposed patch, I do not think it is worth the time to try to make it more advanced now.
Yes it should be strdup'ed somewhere but I am surprised that it works. Look at the start of load_object(): if name != NULL, it searches for existing loaded object with the specified name.
Yes it should be strdup'ed somewhere but I am surprised that it works. Look at the start of load_object(): if name != NULL, it searches for existing loaded object with the specified name. I believe that the right patch would set path somewhere in load_object() in the 'then' case for fd >= 0 (see below).
Thanks. I can confirm that this change also fixes this problem:
I suspect that PATH_FDS is simply not tested enough if such issue popped up. For instance some combination of rpath in the loaded library and unsuccessful load from pathfds could make rtld to try to use refobj path.
Jan 21 2021
Address feedback
Jan 11 2021
Jan 10 2021
Remove unused alias, sort symbols in map file.
Nov 19 2020
Small nit for the copyright section of the man page.
Nov 18 2020
In D17128#608395, @bdrewery wrote:In D17128#371823, @des wrote:I would strongly recommend submitting the sshbuf_{get,put,free}_passwd() part of this patch upstream.
Was this done?