generated from krisnova/rust-nova
-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Execution Authentication #401
Comments
Having seen something like that:
The combination of those 2 factors should give high confidence, that what is actually being executed is the expected and signed binary. But for things with a "container" semantic, I probably still prefer having container images secured by dm-verity. |
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Recently we discussed eBPF architecture in #394.
This conversation called out a potential need for the project to intercept syscall__execve functionality at runtime such that Aurae can instrument any new processes that might be created by a user's workload.
While the original discussion was intended to serve as a potential path to ensure there aren't rogue processes on an Aurae deployment, this begs a set of critical questions for the project.
Should Aurae authenticate all new spawned process to ensure they are anticipated by the runtime?
If it is possible to authenticate every process on a host at runtime, what are the security and supply chain implications of this feature?
I assumed I should kick off the discussion two fold.
The text was updated successfully, but these errors were encountered: