Can someone explain how a system container is more secure than an application container, if that is indeed the case?
About Containers and VMs
21–30 of 63 posts
Re: About Containers and VMs
#22Earlier quoted context omitted.
Which just validates my point that a generic-sounding domain is the wrong place to host content that even within the Linux ecosystem is a relatively minor player.
lxc is used really frequently in the home space (jellyfin/plex for instance). A lot of Proxmox use cases as well which is growing in popularity extremely rapidly.
I really wish I could just run regular docker or oci containers in Proxmox.
Re: About Containers and VMs
#23Can someone explain how a system container is more secure than an application container, if that is indeed the case?
In the context of Incus, they are the same.
Incus and LXC internally use umoci to manipulate the OCI tarball to conform to how LXC runs containers.
See: - https://umo.ci/ - https://github.com/lxc/lxc/blob/lxc-4.0.2/templates/lxc-oci....
Re: About Containers and VMs
#24VMs also don't always require hardware virtualization - Alibaba's PVM https://lkml.org/lkml/2024/2/26/1263 didn't get upstreamed, but, theoretically the MMU is all you need for complete isolation. This kind of idea is also how VM software worked before VT-x was introduced. And of course QEMU has the TCG which works with no kernel support at all.
I think you could also add Xen to that list. IIRC, the old Xen PV mode was purely paravirtualized without using any hardware extensions.
Re: About Containers and VMs
#25What is this? Docker containers can host more than one process/service/app. And why is some product called “Incus” using “linuxcontainers.org” as a domain name?
Linux Containers, or LXC, came before Docker and OCI standardization.
As the others have mentioned, Incus is the community fork led by former members of the LXD team.
Re: About Containers and VMs
#26Can someone explain how a system container is more secure than an application container, if that is indeed the case?
The article is pretty useless at explaining the difference, I agree. It makes claims about Docker that aren't true (e.g. single container) while making inadequate reference to the OS features likely involved in making "system containers" what they are (SECCOMP, capabilities, network namespaces, nftables).
As an engineer this page has a real "trust me bro" feel to it. Maybe fine as a marketing and product positioning thing, but not interesting for HN.
Re: About Containers and VMs
#27Can someone explain how a system container is more secure than an application container, if that is indeed the case?
It generally is more secure just because the system container virtualization system is "more complete", so it's harder to get out from under it.
My understanding with Incus(the OP link) it's the same virtualization system, so there is no real difference, security wise between the two.
The question then becomes can they get out from under the virtualization and can they get access to other machines, containers, etc.
Docker's virtualization system has been very weak security wise. So a system container would be more secure than docker's virtualization system.
Re: About Containers and VMs
#28VMs also don't always require hardware virtualization - Alibaba's PVM https://lkml.org/lkml/2024/2/26/1263 didn't get upstreamed, but, theoretically the MMU is all you need for complete isolation. This kind of idea is also how VM software worked before VT-x was introduced. And of course QEMU has the TCG which works with no kernel support at all.
In my experience TCG (or any method that doesn't require root / admin power) is pretty slow. But I'd be happy to be wrong about that, for an odd project I have
Re: About Containers and VMs
#29Can someone explain how a system container is more secure than an application container, if that is indeed the case?
It's not really.
Any shared resource between containers or the kernel itself is an attack surface.
Both options have a very wide attack surface - the kernel api.
Nothing really beats virtualization in security, the surface shrinks to pretty much just the virtualization bits in the kernel and some user space bits in the VMM.
Re: About Containers and VMs
#30IMO it's not good that the kernel interferences keep on spawning endless userland "middleware" projects.
I still want capsicum to give me sane defaults, so the incentive for sandbox security theater goes away.