Page MenuHomeFreeBSD

capsicumUmbrella
ActivePublic

Recent Activity

Jun 5 2021

freqlabs closed D24832: libcasper: Create a minimal cap_netdb service.
Jun 5 2021, 12:37 PM · capsicum

Apr 6 2021

oshogbo accepted D24832: libcasper: Create a minimal cap_netdb service.

LGTM.
Do you have commit bit or should I commit this?

Apr 6 2021, 8:21 AM · capsicum

Mar 26 2021

freqlabs added a comment to D24832: libcasper: Create a minimal cap_netdb service.

@oshogbo okay to commit?

Mar 26 2021, 7:23 PM · capsicum

Feb 2 2021

kib closed D28442: Fix null-pointer dereference in rtld.
Feb 2 2021, 2:15 PM · capsicum

Feb 1 2021

theraven added a comment to D28442: Fix null-pointer dereference in rtld.

Thanks, I'll see if I can chase this down later. My commit bit lapsed, please can you land it?

Feb 1 2021, 3:36 PM · capsicum
kib accepted D28442: Fix null-pointer dereference in rtld.

Ok, go ahead with the proposed patch, I do not think it is worth the time to try to make it more advanced now.

Feb 1 2021, 3:17 PM · capsicum
theraven updated the diff for D28442: Fix null-pointer dereference in rtld.
Feb 1 2021, 3:11 PM · capsicum
theraven added a comment to D28442: Fix null-pointer dereference in rtld.

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.

Feb 1 2021, 2:35 PM · capsicum
kib added a comment to D28442: Fix null-pointer dereference in rtld.

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).

Feb 1 2021, 12:08 PM · capsicum
theraven added a comment to D28442: Fix null-pointer dereference in rtld.

Thanks. I can confirm that this change also fixes this problem:

Feb 1 2021, 11:52 AM · capsicum
kib added a comment to D28442: Fix null-pointer dereference in rtld.

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.

Feb 1 2021, 11:11 AM · capsicum
theraven requested review of D28442: Fix null-pointer dereference in rtld.
Feb 1 2021, 9:33 AM · capsicum

Jan 21 2021

freqlabs updated the diff for D24832: libcasper: Create a minimal cap_netdb service.

Address feedback

Jan 21 2021, 12:16 AM · capsicum

Jan 11 2021

kib closed D28088: libthr: wrap pdfork(2), same as fork(2)..
Jan 11 2021, 9:02 PM · capsicum
markj accepted D28088: libthr: wrap pdfork(2), same as fork(2)..
Jan 11 2021, 2:53 PM · capsicum

Jan 10 2021

kib updated the diff for D28088: libthr: wrap pdfork(2), same as fork(2)..

Remove unused alias, sort symbols in map file.

Jan 10 2021, 11:15 PM · capsicum
kib added inline comments to D28088: libthr: wrap pdfork(2), same as fork(2)..
Jan 10 2021, 11:14 PM · capsicum
markj accepted D28088: libthr: wrap pdfork(2), same as fork(2)..
Jan 10 2021, 11:04 PM · capsicum
kib requested review of D28088: libthr: wrap pdfork(2), same as fork(2)..
Jan 10 2021, 10:27 PM · capsicum

Nov 19 2020

gbe added a comment to D24832: libcasper: Create a minimal cap_netdb service.

Small nit for the copyright section of the man page.

Nov 19 2020, 3:25 PM · capsicum

Nov 18 2020

oshogbo added inline comments to D24832: libcasper: Create a minimal cap_netdb service.
Nov 18 2020, 9:15 PM · capsicum
naito.yuichiro_gmail.com added a comment to D17128: [sshd 7.8p1] avoid to violate capability mode.
In D17128#371823, @des wrote:

I would strongly recommend submitting the sshbuf_{get,put,free}_passwd() part of this patch upstream.

Was this done?

Nov 18 2020, 8:44 AM · capsicum

Nov 17 2020

bdrewery added a comment to D17128: [sshd 7.8p1] avoid to violate capability mode.
In D17128#371823, @des wrote:

I would strongly recommend submitting the sshbuf_{get,put,free}_passwd() part of this patch upstream.

Nov 17 2020, 2:22 AM · capsicum

Nov 16 2020

freqlabs updated the diff for D24832: libcasper: Create a minimal cap_netdb service.
Nov 16 2020, 1:12 AM · capsicum

Oct 26 2020

oshogbo added a comment to D24832: libcasper: Create a minimal cap_netdb service.

I would prefer to commit this version. Sorry for me not responding for a while.

Oct 26 2020, 2:56 PM · capsicum

Oct 25 2020

freqlabs abandoned D24832: libcasper: Create a minimal cap_netdb service.
Oct 25 2020, 10:39 PM · capsicum

Oct 22 2020

yzhong_freebsdfoundation.org updated the diff for D24327: Add new casper execution service.

Added some simple tests, and made changes according to feedback. The biggest change is the addition of cap_exec_t structures, which behave very similarly to fileargs_t structures in cap_fileargs. Now there is no global state on the user's side, and you can now open multiple cap_exec services without issue.

Oct 22 2020, 3:51 PM · capsicum
dch added a watcher for capsicum: dch.
Oct 22 2020, 8:38 AM

Oct 21 2020

markj added inline comments to D24327: Add new casper execution service.
Oct 21 2020, 7:12 PM · capsicum

Oct 20 2020

yzhong_freebsdfoundation.org added inline comments to D24327: Add new casper execution service.
Oct 20 2020, 5:41 PM · capsicum

Oct 19 2020

yzhong_freebsdfoundation.org added a comment to D24327: Add new casper execution service.

Yes, that makes sense.

Oct 19 2020, 5:36 PM · capsicum
tig_freebsdfoundation.org added a comment to D24327: Add new casper execution service.

From my understanding, doing work in the user interface functions is the same as doing work in user program, as they are the same process. It won't be allowed if program is in cap mode.

I understand what you mean. That's why I used pdfork - having the process descriptor lets me wait for the program even in Capability mode. All the current functionality works, so I'd prefer to keep things as it is unless we want the service to do more.

Oct 19 2020, 5:34 PM · capsicum
yzhong_freebsdfoundation.org added a comment to D24327: Add new casper execution service.
Oct 19 2020, 5:26 PM · capsicum
tig_freebsdfoundation.org added inline comments to D24327: Add new casper execution service.
Oct 19 2020, 5:23 PM · capsicum
yzhong_freebsdfoundation.org added a comment to D24327: Add new casper execution service.

From my understanding, doing work in the user interface functions is the same as doing work in user program, as they are the same process. It won't be allowed if program is in cap mode.

I understand what you mean. That's why I used pdfork - having the process descriptor lets me wait for the program even in Capability mode. All the current functionality works, so I'd prefer to keep things as it is unless we want the service to do more.

Oct 19 2020, 5:20 PM · capsicum
oshogbo added a comment to D24327: Add new casper execution service.

From my understanding, doing work in the user interface functions is the same as doing work in user program, as they are the same process. It won't be allowed if program is in cap mode.

Thats right, cap_exec_init, cap_exec_open, cap_exec_close are done potentialy in the sandboxed process.

Oct 19 2020, 5:20 PM · capsicum
tig_freebsdfoundation.org added a comment to D24327: Add new casper execution service.

Doing the work on the user interface side was a conscious decision on my part. What are the disadvantages of doing it this way? And yes, I do plan to write tests.

From my understanding, doing work in the user interface functions is the same as doing work in user program, as they are the same process. It won't be allowed if program is in cap mode.
exec_command is called by Casper which is a different process, so doing work there is desirable.
It's the pattern I've seen from other Casper services.
I could be wrong though, would appreciate if someone could confirm.

Oct 19 2020, 5:17 PM · capsicum
oshogbo added inline comments to D24327: Add new casper execution service.
Oct 19 2020, 5:13 PM · capsicum
oshogbo added a comment to D24327: Add new casper execution service.

I was mistaken we need service like this, we just need to work a little bit more on it.

Oct 19 2020, 5:12 PM · capsicum
tig_freebsdfoundation.org added inline comments to D24327: Add new casper execution service.
Oct 19 2020, 5:08 PM · capsicum
yzhong_freebsdfoundation.org added a comment to D24327: Add new casper execution service.

Doing the work on the user interface side was a conscious decision on my part. What are the disadvantages of doing it this way? And yes, I do plan to write tests.

Oct 19 2020, 5:06 PM · capsicum
tig_freebsdfoundation.org added inline comments to D24327: Add new casper execution service.
Oct 19 2020, 5:04 PM · capsicum
tig_freebsdfoundation.org added a comment to D24327: Add new casper execution service.

Note that in Casper service user interface and Casper backend are separate processes. Casper does all the work and the user interface simply passes and receives parameters.
One issue I noticed is that the code is doing the actual work (closing fds) in the user interface commands cap_exec_open() and cap_exec_close(), this should be done from exec_command(), perhaps via functions cap_exec_command_open() and cap_exec_command_close(). cap_fileargs.c has a good example of how to do this.
Do you plan to add some test cases?

Oct 19 2020, 5:03 PM · capsicum
yzhong_freebsdfoundation.org added a comment to D24327: Add new casper execution service.

Would such an approach work if I don't have the full path of the program to be executed?

Oct 19 2020, 4:41 PM · capsicum
oshogbo added a comment to D24327: Add new casper execution service.

Ou but I guess you wan't your new process not being in sandbox, right?

Oct 19 2020, 4:25 PM · capsicum
oshogbo added a comment to D24327: Add new casper execution service.

Please don't take this an a criticisms I just would like to know the advantages of this approach.

Oct 19 2020, 4:24 PM · capsicum
yzhong_freebsdfoundation.org added a comment to D24327: Add new casper execution service.

I wonder we can't just use fileargs and fexecve?

Oct 19 2020, 4:12 PM · capsicum
yzhong_freebsdfoundation.org added a comment to D24327: Add new casper execution service.

Thinking about it more, the change to FILE* makes it somewhat unintuitive (or impossible?) to execute commands that you neither read from nor write to. Initially, I made the change because I was doing:
1 - get a file descriptor from cap_exec_open
2 - call fdopen() on it to get a FILE* to work with
3 - later, close the file descriptor with cap_exec_close
But at this point I'm left with a 'dangling' FILE*. I can't call fclose on it as it gives me an unsurprising "bad file descriptor" error. So at this point I felt that it was more sensible for cap_exec to work with FILE*s, since it matches popen in any case. But now, I see that returning a FILE* doesn't make sense in all cases.

Oct 19 2020, 4:07 PM · capsicum
oshogbo added a comment to D24327: Add new casper execution service.

I wonder we can't just use fileargs and fexecve?

Oct 19 2020, 3:56 PM · capsicum
yzhong_freebsdfoundation.org updated the diff for D24327: Add new casper execution service.

In the process of Capsicumizing sort(1), I found that I couldn't properly close the file descriptors that came from this service. It used to return the file descriptor of a FILE* opened via popen(3). This meant that the user can't use pclose to close the file descriptor they receive; pclose expects the same FILE * that popen returned, which the user can't recover. Pclose is responsible for waiting until the opened process ends, and if it isn't called, the user will get concurrency issues (like writing to a file, "closing" it, and then trying to read from it before the write actually finishes).

Oct 19 2020, 3:44 PM · capsicum