111–120 of 140 posts
Please post a tl;dr at the top or even in the subject. Many of us are scrambling to patch/reboot our **.
tl;dr: switch to podman :-) or (for docker, not mention in the post but...) just `allowPrivilegeEscalation=False` in the deployment's SCC and you'll be fine at the pod level. Most deployments don't need priv escalation anyway, the ones that do need to either limits perms through capabilities or make sure the node (meaning the kernel) is patched.
Earlier quoted context omitted.
I just contributed this [1] which does what you want for seccomp. Well, not by default, but profiling is now effective against this attack. Oh, an this [2] just happened [1] https://github.com/containers/oci-seccomp-bpf-hook/pull/209 [2] https://github.com/moby/moby/pull/52501
Blanket blocking socketcall() caused regressions for all 32-bit applications trying to make sockets. In theory, glibc disables socketcall when running on kernel version >= 4.3. In practice, Debian/Fedora/Ubuntu all set glibc's "expected kernel version" to 3.2, so socketcall() is still used on most 32-bit glibc binaries shipped. https://salsa.debian.org/glibc-team/glibc/-/blob/sid/debian/... https://src.fedoraproject.…
I think it was a bad idea to put cryptographic APIs or VPN in the kernel. If userspace is too slow for this, you should either reduce context switch overhead, or create special kind of processes, which are isolated, but quick to switch into. They are repeating Windows mistakes.
We need on disk encryption, and we need to be able boot from an encrypted disk. So we need encryption for that.
We need network filesystems, and we need the traffic over the network to be encrypted. So we need encryption.
IPsec, for better or for worse, is authenticated and partially encrypted at the transport layer, so if we want a linux machine to speak IPsec, we need encryption.
Fixing/changing this would require a huge restructuring of the kernel; it would basically require switching to a microkernel. Given the fact that nobody's ever written a microkernel that doesn't completely suck ass, I don't know that it would be worth the effort.
I think it was a bad idea to put cryptographic APIs or VPN in the kernel. If userspace is too slow for this, you should either reduce context switch overhead, or create special kind of processes, which are isolated, but quick to switch into. They are repeating Windows mistakes.
I like the idea of keeping stuff out of the kernel as much as possible, but in this case, there are good reasons why cryptography has to live in the kernel. We need on disk encryption, and we need to be able boot from an encrypted disk. So we need encryption for that. We need network filesystems, and we need the traffic over the network to be encrypted. So we need encryption. IPsec, for better or for worse, is authen…
If I understand correctly, rootfull podman with --userns=auto would also prevent the privilege escalation ?
How?
Earlier quoted context omitted.
How?
--userns=auto asign a different namespace for each container, so if you escape it you get a random uid far far away from root it also protects other containers from the compromise since they each have their own namespace and uid/gid range, the drawback though is that you can't mount shared volume unless you use a pod, since you would see files from outside your uid/gid range as owned by nobody and inaccessible.
I think it was a bad idea to put cryptographic APIs or VPN in the kernel. If userspace is too slow for this, you should either reduce context switch overhead, or create special kind of processes, which are isolated, but quick to switch into. They are repeating Windows mistakes.
I like the idea of keeping stuff out of the kernel as much as possible, but in this case, there are good reasons why cryptography has to live in the kernel. We need on disk encryption, and we need to be able boot from an encrypted disk. So we need encryption for that. We need network filesystems, and we need the traffic over the network to be encrypted. So we need encryption. IPsec, for better or for worse, is authen…
Earlier quoted context omitted.
--userns=auto asign a different namespace for each container, so if you escape it you get a random uid far far away from root it also protects other containers from the compromise since they each have their own namespace and uid/gid range, the drawback though is that you can't mount shared volume unless you use a pod, since you would see files from outside your uid/gid range as owned by nobody and inaccessible.
That might make Copy Fail harder to exploit, but I still wouldn’t bet money on CF being impossible to use in that scenario.
Earlier quoted context omitted.
You are obviously right that these are similar in principle: VM isolation exploit would lead to the same exposure like container-related isolation exploits. VMs are considered vastly better because the surface area where exploits can happen is smaller and/or better isolated within the kernel. If you are arguing the latter is not true — and we are all collectively hand-waving away big chunk of the surface area so that…
I would say it's the fact that "not a security boundary" appears to be a pass/fail statement, whereas the reality is more like a security continuum, along which VMs are further than containers.
Security is obviously a continuum (eg. you can even have a bug in your IPMI FW, and a network packet could break in without any interaction with the OS; or there could be a HW bug too), but there is a discrete "jump" between containers and VMs to the extent that it is useful to call one a security boundary and the other not. Just like a firewall is a security boundary even if it can have security bugs.
Whether this jump between exploitable surface area warrants this distinction is what the point is: many believe it does.