Live data from Hacker News

Podman rootless containers and the Copy Fail exploit

garrido.io

21–27 of 27 posts

Re: Podman rootless containers and the Copy Fail exploit

#21

Has anyone made a sandbox site running every type of container and presenting a shell where users can try to break out of any uncompromised ones remaining? It's self-evident that we should only run containers that haven't been pwned yet. I suspect that with all of the CVE-20XX exploits, Heartbleed, Meltdown, Rowhammer, Spectre, etc, that we're all living in a fantasy and there simply are no secure containers.

Seems a good place to repeat a quote from Theo de Raadt:

You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.

He'd probably say the same about container architectures.

Re: Podman rootless containers and the Copy Fail exploit

#23
post #2

This is kind of an odd article to me. The point that podman may provide better isolation that Docker is made, but copy fail part focuses on the sample exploit (that overwrote su) which is not super applicable to containerised environments, and not the general effect of exploiting the vulnerability, which is to allow the user to overwrite a file that they should only have read-only access to. https://github.com/Perciv…

The k8s exploit requires stars to be aligned for an external attacker: the pod you exploit (via an RCE?) must share some layers with a privileged pod running in the same node. Or alternatively, you should have the ability to run an arbitary image as an unprivileged pod. Which is surely, some environments where internal teams might have such access. But getting there for a remote attacker isn't easy.

Re: Podman rootless containers and the Copy Fail exploit

#24
post #12
post #11

Earlier quoted context omitted.

Long ago in Linux if you wanted to listen on a privileged port (< 1024) you had to do so as root.

If you're connecting to a host on a port < 1024, then you know a SysAdmin must have set it up, and it must be trustworthy. It was a simpler time.

It's more that Unix systems were timesharing systems, any user could run a daemon, but you didn't want users to have the ability to grab a port used by system services, not just because they could impersonate a system service on the network, but also because then you couldn't trust localhost services, either, as well as it just being a PITA. This is still true today; though vanishingly few Linux systems are multi-tenant, it's still common to implicitly trust a local service.

Re: Podman rootless containers and the Copy Fail exploit

#26
post #11

Earlier quoted context omitted.

Long ago in Linux if you wanted to listen on a privileged port (< 1024) you had to do so as root.

is that no longer true?

If the application supports it, there’s also systemd socket activation (or traditional inetd sorta stuff too if that fits)

Re: Podman rootless containers and the Copy Fail exploit

#27
post #26

Earlier quoted context omitted.

is that no longer true?

If the application supports it, there’s also systemd socket activation (or traditional inetd sorta stuff too if that fits)

Forgot to mention: you can use systemd-socket-proxyd to bridge to an application that doesn't support socket activation too: https://www.man7.org/linux/man-pages/man8/systemd-socket-pro...
Post reply on HN