syscalls: native or translated
Hi there, I just had a talk with some LXC nerds. Their opinion is that unprivileged LXC is more secure than Docker and similar solutions. These would translate the syscalls to userspace, to not have a direct interface to the kernel. In LXC, the syscalls themselves would have built-in namespace awareness in the kernel itself, but without a translation layer. How does this statement relate to the security of a container running in rootless Podman in a normal user? Could the "translation layer" introduce trouble? Best regards, Tobias
On Mon, Oct 04, 2021 at 05:09:33PM +0200, Tobias Wendorff wrote:
I just had a talk with some LXC nerds.
Their opinion is that unprivileged LXC is more secure than Docker and similar solutions. These would translate the syscalls to userspace, to not have a direct interface to the kernel. In LXC, the syscalls themselves would have built-in namespace awareness in the kernel itself, but without a translation layer.
How does this statement relate to the security of a container running in rootless Podman in a normal user? Could the "translation layer" introduce trouble?
I am really confused about the translation layer you are mentioning I have not heard of it before. I just had a short chat with the core LXC maintainer and he also says this email is mainly confusing. It seems like your source of information is not reliable of confusing certain concepts. Can you maybe be a bit more specific what you are looking for? Adrian
On Tue, Oct 5, 2021, 09:53 Adrian Reber <adrian@lisas.de> wrote:
On Mon, Oct 04, 2021 at 05:09:33PM +0200, Tobias Wendorff wrote:
I just had a talk with some LXC nerds.
Their opinion is that unprivileged LXC is more secure than Docker and similar solutions. These would translate the syscalls to userspace, to not have a direct interface to the kernel. In LXC, the syscalls themselves would have built-in namespace awareness in the kernel itself, but without a translation layer.
How does this statement relate to the security of a container running in rootless Podman in a normal user? Could the "translation layer" introduce trouble?
I am really confused about the translation layer you are mentioning I have not heard of it before.
Maybe seccomp with BPF filtering is meant. There's the userspace notification mechanism which does something like this.
I just had a short chat with the core LXC maintainer and he also says this email is mainly confusing. It seems like your source of information is not reliable of confusing certain concepts. Can you maybe be a bit more specific what you are looking for?
Adrian _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
On Tue, Oct 05, 2021 at 11:46:39AM +0200, Michael Lausch wrote:
On Tue, Oct 5, 2021, 09:53 Adrian Reber <adrian@lisas.de> wrote:
On Mon, Oct 04, 2021 at 05:09:33PM +0200, Tobias Wendorff wrote:
I just had a talk with some LXC nerds.
Their opinion is that unprivileged LXC is more secure than Docker and similar solutions. These would translate the syscalls to userspace, to not have a direct interface to the kernel. In LXC, the syscalls themselves would have built-in namespace awareness in the kernel itself, but without a translation layer.
How does this statement relate to the security of a container running in rootless Podman in a normal user? Could the "translation layer" introduce trouble?
I am really confused about the translation layer you are mentioning I have not heard of it before.
Maybe seccomp with BPF filtering is meant. There's the userspace notification mechanism which does something like this.
Yes, I also thought that this might be it. But it is a LXD and not a LXC feature if I remember it correctly. Adrian
Dear Adrian, Am 05.10.2021 um 09:44 schrieb Adrian Reber:
I am really confused about the translation layer you are mentioning I have not heard of it before.
Me neither. That's why I asked.
I just had a short chat with the core LXC maintainer and he also says this email is mainly confusing. It seems like your source of information is not reliable of confusing certain concepts. Can you maybe be a bit more specific what you are looking for?
Those were not my words. I've just refactored some sentences in a long discussion about the benefits of a rootless and daemonless Podman vs. LXC (I got the permission to repost them). I'll talk to him again. Maybe he also was confused. Thanks for your reply, Tobias
On 10/5/21 09:35, Tobias Wendorff wrote:
Dear Adrian,
Am 05.10.2021 um 09:44 schrieb Adrian Reber:
I am really confused about the translation layer you are mentioning I have not heard of it before.
Me neither. That's why I asked.
I just had a short chat with the core LXC maintainer and he also says this email is mainly confusing. It seems like your source of information is not reliable of confusing certain concepts. Can you maybe be a bit more specific what you are looking for?
Those were not my words. I've just refactored some sentences in a long discussion about the benefits of a rootless and daemonless Podman vs. LXC (I got the permission to repost them).
I'll talk to him again. Maybe he also was confused.
Thanks for your reply, Tobias _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
Perhaps lxcd is using some kind of seccomp filtering kernel. Podman theoretically supports gVistord as a OCI Runtime, which intercepts all Syscalls of the container. You could also use kata oci runtime to do the syscalls within a qumu kvm process. libkrun provides similar functionality. Bottom line by default rootless Podman communicates with the host kernel just like normal user processes, with tools like SELinux, Seccomp filtering and user namespace to further isolate the processes. A kernel vulnerability with standard traditional OCI Runtimes, could lead to a privilege escallation with these containers. If you run with another syscall intercepter or with kvm, you get better isolation. Podman can run in either mode.
Am 05.10.2021 um 16:58 schrieb Daniel Walsh:
Perhaps lxcd is using some kind of seccomp filtering kernel. Podman theoretically supports gVistord as a OCI Runtime, which intercepts all Syscalls of the container. You could also use kata oci runtime to do the syscalls within a qumu kvm process. libkrun provides similar functionality.
I've played around with "ignite", which uses Firecracker. But because of the update of the shim API (?), it shot itself incompatible with Podman. Thanks for `libkrun`, I'll give it a try. Back to the topic: I understood his comment that way that he approved of LX[C,D] having direct access to the kernel as a benefit, while Podman and others have a "transition layer". I think the original author misunderstood something there, since this seems to be wrong. He's also in IRC in channel ##proxmox. Maybe we can clarify this.
participants (4)
-
Adrian Reber -
Daniel Walsh -
Michael Lausch -
Tobias Wendorff