search

aurae-runtime / aurae

Distributed systems runtime daemon written in Rust.
https://aurae.io
Apache License 2.0
1.85k stars 91 forks source link

Execution Authentication #401

Open krisnova opened 1 year ago

krisnova commented 1 year ago

Recently we discussed eBPF architecture in https://github.com/aurae-runtime/aurae/issues/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.

  1. How exactly would we pull this off? What can we learn from packet level authentication in other parts of the kernel?
  2. Do we actually care about this? If so... why? Specifically? What specific security features does this unlock?
maxfragg commented 1 year ago

Having seen something like that:

  1. Signature verification using binfmt-misc mechanism
  2. Monitoring processes using netlink connector
  3. To make life easier: prevent fork/fork like clone using seccomp for everything that should not create subprocesses

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.