Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

About Containers and VMs

linuxcontainers.org

Post reply on HN
Print view View original

31–40 of 63 posts

Re: About Containers and VMs

#31

Post by SirGiggles »

thundergolfer wrote: post #26
reilly3000 wrote: post #21

Can 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…

This has been one personal pet peeve with the documentation surrounding Incus.

As a stack, Incus has been exceptional, it has largely replaced Proxmox and Podman Quadlets for me. For context, I homelab so I cannot generalize my claim to SMB or enterprise.

But the documentation has been very end user oriented, information regarding specifics like seccomp as you mentioned are only discoverable with the search bar and that leads to various disparate locations; and that also isn't taking into account that some of the more nitty gritty information isn't on the Incus portion of linuxcontainers.org, see the LXC Security page for example: https://linuxcontainers.org/lxc/security/

Re: About Containers and VMs

#32

Post by eru »

SirGiggles wrote: post #24
mappu wrote: post #20

VMs 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.

Yes, Xen was big on paravirtualisation but started supporting the other kinds pretty soon, too. (At least they were supported around 2009-2012, when I was working on XenServer.)

Re: About Containers and VMs

#33

Post by eru »

01HNNWZ0MV43FF wrote: post #28
mappu wrote: post #20

VMs 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

It depends a bit on your workload. If you have a pure computation workload, without much IO, TCG etc doesn't need to be slow.

Re: About Containers and VMs

#34

Post by SirGiggles »

eru wrote: post #32
SirGiggles wrote: post #24

Earlier quoted context omitted.

I think you could also add Xen to that list. IIRC, the old Xen PV mode was purely paravirtualized without using any hardware extensions.

Yes, Xen was big on paravirtualisation but started supporting the other kinds pretty soon, too. (At least they were supported around 2009-2012, when I was working on XenServer.)

I think things are swinging back the other way if I have understood the more recent PVHv2 stuff correctly.

Re: About Containers and VMs

#35

Post by falcojr »

hliyan wrote: post #9

As I always say: a VM makes an OS believe that it has the machine to itself; a container makes a process believe that it has the OS to itself.

That's literally the opposite of what this documentation is explaining. System containers exist. You can run the entire userspace of an OS (including systemd) in a container.

Re: About Containers and VMs

#36

Post by jeltz »

Ericson2314 wrote: post #30

IMO 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.

Seems mostly off topic to the article. I think system containers should be implemented in user space. They are not about security theatre but about getting a sandboxed environment which feels like a real/virtual machine but is lighter weight. Very useful e.g. when I want to emulate a whole cluster of Linux machines. And for those needs security is nice but not key.

It is application containers which maybe should be replaced by better kernel security, not system containers.

Re: About Containers and VMs

#37

Post by hamandcheese »

fulafel wrote: post #19
hliyan wrote: post #9

As I always say: a VM makes an OS believe that it has the machine to itself; a container makes a process believe that it has the OS to itself.

I think they linuxcontainers.org people would disagree. Like the table is trying to communicate, in contrast to eg Docker, this is not about application containerization.

The table is comparing all three types: VM, system containers, application containers. Incus supports application containers. Its a relatively recent addition.

I can't find great docs for it, but its in the release notes last year: https://linuxcontainers.org/incus/news/2024_07_12_05_07.html

Re: About Containers and VMs

#38

Post by fulafel »

reilly3000 wrote: post #21

Can someone explain how a system container is more secure than an application container, if that is indeed the case?

Complexity is generally the enemy of security, because securing a system requires understanding it. If you can build a more understandable, less moving parts, more observable, more easily manageable etc system with system containers, it's a security argument.

Re: About Containers and VMs

#39

Post by abhinavk »

hliyan wrote: post #9

As I always say: a VM makes an OS believe that it has the machine to itself; a container makes a process believe that it has the OS to itself.

And a system container makes an OS (or OS userland) believe that that it has the kernel to itself.
Post reply on HN