You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It may be a good idea to add seccomp support to Resurgence to further enforce secure computing. I see two ways we could implement this feature:
The first way we could implement it would look something like this:
When the interpreter instance is created, it also creates a new seccomp thread that listens on an internal IPC interface, such as shared memory or a FIFO pipe
Whenever any future calls are made to the interpreter, they are forwarded to the seccomp thread over the IPC interface
When the interpreter instance is destroyed, it ends the seccomp thread
This way, the seccomp functionality is completely internal to Resurgence and is abstracted away from the host application entirely.
We could also implement it the second way, which would look something like this:
Resurgence provides some sort of seccomp_enable and seccomp_disable functions in the API
The host application directly sets up and tears down the seccomp thread and runs the entire Resurgence VM inside of it
This would be more secure, but would make it much more difficult to use for developers of host applications.
The text was updated successfully, but these errors were encountered:
It may be a good idea to add seccomp support to Resurgence to further enforce secure computing. I see two ways we could implement this feature:
The first way we could implement it would look something like this:
This way, the seccomp functionality is completely internal to Resurgence and is abstracted away from the host application entirely.
We could also implement it the second way, which would look something like this:
This would be more secure, but would make it much more difficult to use for developers of host applications.
The text was updated successfully, but these errors were encountered: