Decide whether and how to add default syscalls to the SeccompProfile CRD about security-profiles-operator HOT 3 CLOSED

I agree this is a though topic. Maybe we could start with documentation around that topic and explain to the user:

• Which syscalls are going to be expected by nearly every workload, because they're required by the OCI runtime (like runc)
• Which syscalls are additionally required, for example to run kubectl exec -it …

We could scope the documentation on an x86_64 environment and describe that this will differ on different architectures.

Adding the minimal example as well as an e2e test around it seems like a good idea, too. We can show to the user how to use that minimal profile as a starting base for profile development. And that brings me to the next question: Would it be possible to stack/combine two profiles now that we have a CRD? We could define a new field baseProfile for a CRD and afterwards just merge them together and write it on disk, right?

from security-profiles-operator.

Would it be possible to stack/combine two profiles now that we have a CRD? We could define a new field baseProfile for a CRD and afterwards just merge them together and write it on disk, right?

I think that could work...so it would look something like this:

---
kind: SeccompProfile
metadata:
  name: base
spec:
  defaultAction: SCMP_ACT_ERRNO
  syscalls:
  - action: SCMP_ACT_ALLOW
    names:
    - capget
    - ...
---
kind: SeccompProfile
metadata:
  name: hello-world
spec:
  baseProfile: base
  targetWorkload: hello
  syscalls:
  - action: SCMP_ACT_ALLOW
    names:
    - arch_prctl
    - ...
  - action: SCMP_ACT_LOG
    names:
    - pause
    - ...

/var/lib/kubelet/seccomp/operator/default/hello/hello-world.json:

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "syscalls": [
    {
      "action": "SCMP_ACT_ALLOW",
      "names": ["capget", "arch_prctl", ...]
    },
    {
      "action": "SCMP_ACT_LOG",
      "names": ["pause", ...]
    }
  ]
}

Still, what should happen if there are syscalls with different actions in the base versus user-defined profile? e.g.

base:

  syscalls:
  - action: SCMP_ACT_ALLOW
    names:
    - capget

user-defined:

  syscalls:
  - action: SCMP_ACT_ERRNO
    names:
    - capget

merged:

...
  "syscalls": [
    {
      "action": "SCMP_ACT_ALLOW",
      "names": ["capget",...]
    },
    {
      "action": "SCMP_ACT_ERRNO",
      "names": ["capget", ...]
    }

That would be an invalid profile, I think? But I guess no different than if the user had created just a single invalid profile...

from security-profiles-operator.

Would it be possible to stack/combine two profiles now that we have a CRD? We could define a new field baseProfile for a CRD and afterwards just merge them together and write it on disk, right?

I think that could work...so it would look something like this:

---
kind: SeccompProfile
metadata:
  name: base
spec:
  defaultAction: SCMP_ACT_ERRNO
  syscalls:
  - action: SCMP_ACT_ALLOW
    names:
    - capget
    - ...
---
kind: SeccompProfile
metadata:
  name: hello-world
spec:
  baseProfile: base

What about baseProfileName to have a more strict reference?

…
merged:

...
  "syscalls": [
    {
      "action": "SCMP_ACT_ALLOW",
      "names": ["capget",...]
    },
    {
      "action": "SCMP_ACT_ERRNO",
      "names": ["capget", ...]
    }

That would be an invalid profile, I think? But I guess no different than if the user had created just a single invalid profile...

Yes, in the first iteration we could leave out those validation steps from my point of view. But it would be a good addition to check for syntactically, but logically wrong profiles later on. 👍

Thinking about some other pitfalls here but I do not see anything right now…

from security-profiles-operator.