Comment by tux3
What's the status of Landlock in container runtimes? A quick search makes it seem like CRIs are trying to define their own custom Landlock interface.
That will inevitably lag behind what the kernel supports, but more importantly I don't foresee many container image packagers, Helm recipe maintainers and other YAML wranglers getting into the business of maintaining a Landlock sandbox policy.
It makes sense for an application to use Landlock directly to sandbox some parser or other sensitive component. But if the CRI just blocks the syscalls by default, no infra person is going to take on the maintainance of their own sandbox policy for every app. The app will just see ENOSYS and not be sandboxed.
I might be missing the whole idea here, but I really don't see why we need some custom layer in the middle instead of having container runtimes let the security syscalls through?
> A quick search makes it seem like CRIs are trying to define their own custom Landlock interface.
Are you referring to [0, 1]?
> But if the CRI just blocks the syscalls by default
Does it? Where are you getting this from?
> I might be missing the whole idea here, but I really don't see why we need some custom layer in the middle instead of having container runtimes let the security syscalls through?
Because in the latter case you have to trust the application it will actually do the appropriate locking?
[0]: https://github.com/opencontainers/runc/issues/2859
[1]: https://github.com/opencontainers/runtime-spec/issues/1110