Support Landlock LSM? #2859
Comments
|
Landlock is trying to solve a separate problem and doesn't really help with the libseccomp issues we have -- Landlock is a new LSM (Linux Security Module) and it's probably better to compare it with AppArmor or SELinux. It does have some similarities with seccomp (it uses BPF -- though it uses eBPF while seccomp is restricted to cBPF) but aside from that it's not really comparable (and it doesn't replace seccomp's primary use-case -- removing kernel attack surface by disabling syscall entrypoints). It should be noted that the issues we've had recently are purely related to libseccomp, not with seccomp itself. The solution we applied still uses seccomp, it just works around the limitations of libseccomp's filter generation. |
I was thinking that - if it performs as advertised - the availability of those syscall entry points would be irrelevant as long as one cannot do anything with them (because they access or manipulate kernel structures that are blocked by landlock) - i.e. getting EPERM for anything you try to do with them, unless they don't exist on that box (-> ENOSYS), which would give the "canonically" correct errors within the container, without having to go through the leaky abstraction of the syscall-profiles. |
|
Well, that is the argument behind LSMs in general (they restrict access to kernel objects). However that assumes there are no bugs in the LSM -- what seccomp does is that completely removes the ability to access kernel code that may be buggy (such as compat or old and unmaintained syscalls). LSMs simply cannot do that because they are applied so far into syscall execution that you've already run most of the code that might be buggy. Seccomp doesn't solve many other problems that LSMs try to solve, but it does solve this problem that LSMs simply cannot. (And this isn't hypothetical, quite a few kernel 0days were blocked by seccomp policies because the buggy kernel code in question simply could not be reached by the container.) |
|
Well-understood, thanks for the explanation - at least I wasn't completely off with my understanding of the mechanics. Would it make sense to consider using both though? That would also allow the user (or at least profile-maintainer) to specify a hybrid approach where e.g. seccomp is only used to filter out the "old and unmaintained" syscalls, and leaves the rest to the LSM. |
|
Well, landlock isn't upstream yet. But once it is I imagine we'd add support to it in the runtime-spec (just like we support SELinux and AppArmor today). |
FYI, it landed in -next a couple days ago, might make it into 5.13. |
|
Yup, runtime-spec would be the next step but I'd need to look into what model we should use for supporting it (the AppArmor/SELinux "just give me the label" model is not ideal for a few reasons, but same goes for the seccomp model 😦). |
|
Landlock has now been released with Linux 5.13. |
|
Opened an runtime-spec proposal and added with a drafted version there. Any review or comment is much welcome. Thanks a lot. |
|
About the Go support, @gnoack and I are working to move https://github.com/gnoack/golandlock: landlock-lsm/go-landlock#10. This should not take long and I suggest to not use the current location/name but wait for the new one. |
This is done now :) The new location is: |
|
Hi guys!!! I have drafted runc landlock version based on opencontainers/runtime-spec#1111 commits by @kailun-qin for runtime-spec. I wonder if I can send it here for the discussion? Or @kailun-qin has already been working on runc landlock version? |
Hi @BoardzMaster, great to hear that you're also working on it! Yes, internally we have a PoC implementation based on I'd like to propose a convergence on it if you're using the same approach so that the effort won't be wasted. WDYT? You can reach me at kailun.qin@intel.com and let me know if any thoughts. |
This patch introduces Landlock Linux Security Module (LSM) support in runc, which was landed in Linux kernel 5.13. This allows unprivileged processes to create safe security sandboxes that can securely restrict the ambient rights (e.g. global filesystem access) for themselves. runtime-spec: opencontainers/runtime-spec#1111 Fixes opencontainers#2859 Signed-off-by: Kailun Qin <kailun.qin@intel.com>
|
Hi @BoardzMaster, I've proposed my drafted version of PR here: #3194. See if you have anything to add/converge or any thoughts. I would be happy to add co-authors. Hi All, please kindly take a look when you get a chance. Thanks a lot! P.S. There should be a follow-up patch for integration testing. |
Thank you so much @kailun-qin. I will check it. |
This patch introduces Landlock Linux Security Module (LSM) support in runc, which was landed in Linux kernel 5.13. This allows unprivileged processes to create safe security sandboxes that can securely restrict the ambient rights (e.g. global filesystem access) for themselves. runtime-spec: opencontainers/runtime-spec#1111 Fixes opencontainers#2859 Signed-off-by: Kailun Qin <kailun.qin@intel.com>
With the discussions about some of the limitations of (lib)seccomp (#2151, #2735 etc.), especially in the context of determining which error to return for syscalls that may or may not be around at runtime, the following caught my eye.
I presume most people here are aware of the series of "landlock" patches that have been through 30 iterations over the last 5 years. The cover letter states:
I don't pretend to understand well enough if this could - in principle - solve some of the problems around the returned errors or other tricky bits in that regard, but it sounded intriguing - i.e. if that whole error dance could be avoided by letting landlock rather than seccomp handle things.
If landlock's approach is fundamentally unsuited to solving the problems here, I apologise. If OTOH there are only a few things missing for it to be usable, perhaps it would be a good time to reach out on LKML to see if they can be closed (or at least roadmapped) before the series is merged (looks like it's finalising).
The text was updated successfully, but these errors were encountered: