8 ms·

If built to spec, then the various container technologies in the kernel used together are theoretically secure. It closes all of the holes that we know about, a

If built to spec, then the various container technologies in the kernel used together are theoretically secure. It closes all of the holes that we know about, aside from a few trivial things like the container spying on process id numbers on the host, and of course the vast potential to accidentally misconfigure it. However, all this code is quite complex, and the kernel and the software ecosystem are lacking in having a layered approach to security that goes all the way down to the low-level nitty gritty stuff. For example, kernel memory structures are not robustly protected against the usual memory exploits, and there isn't as strong W^X protection as desired. Windows, in contrast, is able to provide layered security through a variety of approaches, including running the entire operating system in a virtual machine, with the host ensuring integrity of kernel memory. These sorts of layered approaches to security are desirable because there will always be defects in any complex software. Side note: AppArmor and bwrap are distinct. Bubblewrap is a relatively simple userspace program that makes use of existing kernel containerization features (the same ones that Docker/Podman use), whereas AppArmor and SELinux are security features that are patched into the kernel itself. AppArmor and SELinux have made some progress in adding layered low-level security to the kernel, but it's not particularly impressive. Bubblewrap has done great work in exposing the kernel's existing tech to users, but they are not fundamental improvements to the kernel itself.

viraptor 3y ago
> aside from a few trivial things like the container spying on process id numbers on the host Containers with own PID namespace can't spy on process IDs on the host though? Not sure what you mean here. > and there isn't as strong W^X protection as desired What level is desired? Bootup warnings for W^X got merged a while ago. Changes that try to include anything violating it are rejected (see bcachefs). > Windows, in contrast, is able to provide layered security through a variety of approaches, including running the entire operating system in a virtual machine, with the host ensuring integrity of kernel memory. What? Xen existed for years, that's not "in contrast". Secureboot and lockdown exists on Linux too. There's also per-service firecracker microvm. > whereas AppArmor and SELinux are new security features that are patched into the kernel itself That's very misleading. They're not new - selinux is over 2 decades old. They're also not "patched in" - LSMs have been integrated into Linux for a very long time with multiple implementations available. Selinux had multilabel security created for gov use. It's quite impressive actually.
- creatonez 3y ago
  > That's very misleading. They're not new - selinux is over 2 decades old. I misspoke on SELinux and AppArmor being "new". What I was getting at is that they are distinct kernel features, compared to bwrap which is just a user of kernel features already familiar in this discussion. So "new", as in, "additional", e.g. "We turned up some new evidence from the old files". And yes, SELinux is included as a first-class kernel feature. AppArmor is a bit different because it still has a lot of hurdles before all its features can be upstreamed. However, upstreaming is not the end-all-be-all so it's not necessarily a bad thing that parts of AppArmor are patched in, so I'm not emphasizing this point at all. > What? Xen existed for years, that's not "in contrast". Does the Xen or KVM ecosystems provide anything comparable to Windows hypervisor-enforced code integrity? That is, the host is aware of what kernel memory needs to be set to read-only or checked regularly for corruption or irregularities, in a system that is impossible to interfere with without a VM break. (https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-vbs https://learn.microsoft.com/en-us/windows-hardware/design/de... ) Secure VMs are great, VMs that are actually monitoring and enhancing the security of the code running inside are even better.
  - viraptor 3y ago
    > Does the Xen or KVM ecosystems provide anything comparable to Windows hypervisor-enforced code integrity? Xen can do it, KVM had some attempts at memory enforcement patches, but not sure where it ended up. I'm not sure how well utilised it is though from the guest side ootb. (I think poorly) A lot of the signing/module loading issues are prevented on the guest side though with https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html So it's... not the same, but the facilities are available. (Unless someone wants to correct me and it's already used)

viraptor 3y ago

> aside from a few trivial things like the container spying on process id numbers on the host Containers with own PID namespace can't spy on process IDs on the host though? Not sure what you mean here. > and there isn't as strong W^X protection as desired What level is desired? Bootup warnings for W^X got merged a while ago. Changes that try to include anything violating it are rejected (see bcachefs). > Windows, in contrast, is able to provide layered security through a variety of approaches, including running the entire operating system in a virtual machine, with the host ensuring integrity of kernel memory. What? Xen existed for years, that's not "in contrast". Secureboot and lockdown exists on Linux too. There's also per-service firecracker microvm. > whereas AppArmor and SELinux are new security features that are patched into the kernel itself That's very misleading. They're not new - selinux is over 2 decades old. They're also not "patched in" - LSMs have been integrated into Linux for a very long time with multiple implementations available. Selinux had multilabel security created for gov use. It's quite impressive actually.

creatonez 3y ago
> That's very misleading. They're not new - selinux is over 2 decades old. I misspoke on SELinux and AppArmor being "new". What I was getting at is that they are distinct kernel features, compared to bwrap which is just a user of kernel features already familiar in this discussion. So "new", as in, "additional", e.g. "We turned up some new evidence from the old files". And yes, SELinux is included as a first-class kernel feature. AppArmor is a bit different because it still has a lot of hurdles before all its features can be upstreamed. However, upstreaming is not the end-all-be-all so it's not necessarily a bad thing that parts of AppArmor are patched in, so I'm not emphasizing this point at all. > What? Xen existed for years, that's not "in contrast". Does the Xen or KVM ecosystems provide anything comparable to Windows hypervisor-enforced code integrity? That is, the host is aware of what kernel memory needs to be set to read-only or checked regularly for corruption or irregularities, in a system that is impossible to interfere with without a VM break. (https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-vbs https://learn.microsoft.com/en-us/windows-hardware/design/de... ) Secure VMs are great, VMs that are actually monitoring and enhancing the security of the code running inside are even better.
- viraptor 3y ago
  > Does the Xen or KVM ecosystems provide anything comparable to Windows hypervisor-enforced code integrity? Xen can do it, KVM had some attempts at memory enforcement patches, but not sure where it ended up. I'm not sure how well utilised it is though from the guest side ootb. (I think poorly) A lot of the signing/module loading issues are prevented on the guest side though with https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html So it's... not the same, but the facilities are available. (Unless someone wants to correct me and it's already used)