4 ms·

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

by tux3 11mo ago

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?

ameliaquining 11mo ago
I don't think this is really intended for container runtimes. You might be able to make it work in a square-peg-round-hole sort of way but the core use case is different.
- als0 11mo ago
  If the application in the container wants to add more restrictive rules then it should be allowed to. But it should not be able to mess with the existing rules imposed by the container manager. This would be the ideal outcome.
  - arianvanp 11mo ago
    There is nothing to do here. Landlock already a guarantees that you can't undo rules that were already applied. Your application can further restrict itself but it can't unrestrict itself.
    - als0 11mo ago
      Just need the container manager to not block the landlock system call
codethief 11mo ago
> 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 https://github.com/opencontainers/runc/issues/2859 [1]: https://github.com/opencontainers/runtime-spec/issues/1110 https://github.com/opencontainers/runtime-spec/issues/1110

by tux3 11mo ago

ameliaquining 11mo ago

I don't think this is really intended for container runtimes. You might be able to make it work in a square-peg-round-hole sort of way but the core use case is different.

als0 11mo ago
If the application in the container wants to add more restrictive rules then it should be allowed to. But it should not be able to mess with the existing rules imposed by the container manager. This would be the ideal outcome.
- arianvanp 11mo ago
  There is nothing to do here. Landlock already a guarantees that you can't undo rules that were already applied. Your application can further restrict itself but it can't unrestrict itself.
  - als0 11mo ago
    Just need the container manager to not block the landlock system call

codethief 11mo ago

> 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 https://github.com/opencontainers/runc/issues/2859 [1]: https://github.com/opencontainers/runtime-spec/issues/1110 https://github.com/opencontainers/runtime-spec/issues/1110