Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Get PPID from Executor.Exec call #133

Open
mikelsr opened this issue Jul 14, 2023 · 2 comments
Open

Get PPID from Executor.Exec call #133

mikelsr opened this issue Jul 14, 2023 · 2 comments
Assignees
Labels
help wanted Extra attention is needed Performance Something isn't fast enough security Has security implications

Comments

@mikelsr
Copy link
Contributor

mikelsr commented Jul 14, 2023

An efficient executor implementation requires some sort of process tree. I have implemented the tree in this branch, but populating it is another issue.

@lthibault @aratz-lasa or anyone else, atm I can't figure out a way of implicitly discerning who is making the call and deducing the callers PID (if it has one) from there.

As an alternate path I though about adding a ppid parameter to the exec call, where ppid is the pid of the process making the call. Each process would know its own pid. This means the ppid is easily forge-able, and processes can pass themselves as other processes, even pid=0 which is the PID reserved for the executor.

The solution might be for both executor and processes to have a prv/pub key pair, so the process calling exec signs the ppid with its private key and encrypts it with the executor's public key.

Would you mind giving it a thought to see if we can come up with a better approach? If not, do you know of any lightweight encrypting and signing protocols? Thank you in advance, look forward to hearing your opinions! Ping me in Matrix for quick conversations :)

@mikelsr mikelsr added help wanted Extra attention is needed security Has security implications Performance Something isn't fast enough labels Jul 14, 2023
@mikelsr mikelsr self-assigned this Jul 14, 2023
@mikelsr
Copy link
Contributor Author

mikelsr commented Jul 14, 2023

I need to keep going so for the time being I will be using standard protocols and doing the key-pair thing, but sooner or later this will need to be changed.

@mikelsr
Copy link
Contributor Author

mikelsr commented Jul 14, 2023

I went ahead and implemented it with RSA and the results were... disastrous :,)

In my i7-6700K forking a process takes almost 1 second, 90% of which is singing and encrypting a message from inside a WASM guest and another significant chunk is generating a new key pair for each new process. I am discarding this idea and finding a new approach. Any help is welcome!

I will however create a tag for this version of the code in my local fork so I can reproduce it to document the performance results.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
help wanted Extra attention is needed Performance Something isn't fast enough security Has security implications
Projects
None yet
Development

No branches or pull requests

1 participant