Support a setuid/setcap helper and/or privileged service for networking and/or container setup

[DemiMarie]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind feature

Description

Currently, rootless Podman uses slirp4netns, which is slow and has been a source of security problems in the past. One alternative would be to use native Linux kernel networking. This requires privileges on the host, however, which is why rootless Podman cannot currently support it.

This can be avoided by relying on a privileged daemon on the host, which will have better performance.

[Luap99]

I am really against this.

First of the argument slirp4netns has been a source of security problems in the past doesn't make sense when you ask for a privileged helper program. How can we make sure this helper program would have no security issues? We can't and it it would be much worse since the program would have more privileges that can be exploited. How can we make sure that a user doesn't abuse this and creates interfaces with ip addresses that could conflict with the normal host routing?

I understand the performance part but this still this is not really possible. Because podman always joins the rootless user namespace it cannot execute setuid programs afterwards, the root uid is not mapped. To circumvent this we would require a persistent daemon running. I don't think this is a godd idea. It is certainly against podman principles, we try to avoid daemons as much as possible and it will cause more security problems.

Note that you can do this today manually. Create a netns, configure it manually and use it with --net ns:/path/to/netns or see this mailing list post for an example: https://lists.podman.io/archives/list/podman@lists.podman.io/thread/W6MCYO6RY5YFRTSUDAOEZA7SC2EFXRZE/

[Luap99]

@baude @mheon @rhatdan WDYT?

[rhatdan]

I agree totally with @Luap99. We want to do as much as possible without additional privileges, and talking to privileged daemons shipped by Podman is not something we want to support. Podman needs to work within the constraints of a rootless user. Allowing users to setup their own network namespace and allow that to joined to a Podman container is the best we can do.

[DemiMarie]

I agree totally with @Luap99. We want to do as much as possible without additional privileges, and talking to privileged daemons shipped by Podman is not something we want to support. Podman needs to work within the constraints of a rootless user.

I guess this really needs to be handled on the kernel side, or perhaps by systemd-networkd.

Allowing users to setup their own network namespace and allow that to joined to a Podman container is the best we can do.

The problem with this approach is that it (rather obviously) does not scale.

[rhatdan]

Lets take a step back. What is your goal? Is it to have developers running and building containers via rootless mode, or do you just want to make sure that containers do not have a process in them that is running as full root?

If the second, have you looked at # podman run --userns=auto ...

This command will run podman containers in a unigue UserNS isolated from the host, but be started as root, allowing you flexibility with the network stack. I believe this is the way that containers in production launched by podman should run rather then being launched by a rootless user.

[DemiMarie]

Lets take a step back. What is your goal? Is it to have developers running and building containers via rootless mode, or do you just want to make sure that containers do not have a process in them that is running as full root?

My goal is twofold:

1. Figure out some way to restrict user namespaces to somewhat privileged helper programs, while still allowing unprivileged users to create and use containers. There are a huge number of user ⇒ root kernel vulnerabilities that are only possible when unprivileged user namespaces are enabled, so if I ran a Linux system with multiple mutually-distrusting users I would likely need to turn those off. Flatpak, WebKitGTK+, and GNOME’s thumbnailers all use bubblewrap for sandboxing nowadays, and bubblewrap can still work even if unprivileged user namespaces are off if it is setuid root. This means that one must trust that bubblewrap doesn’t have any privilege escalation vulnerabilities, but it has a better track record in this regard than the kernel code (such as netfilter) that unprivileged user namespaces exposes.
2. Find a replacement for the slirp4netns C code. slirp4netns is a C network stack that has a worse security track record than the kernel’s own network stack. One alternative would be for Podman to include a Go or Rust version of this network stack.

If the second, have you looked at # podman run --userns=auto ...

This command will run podman containers in a unigue UserNS isolated from the host, but be started as root, allowing you flexibility with the network stack. I believe this is the way that containers in production launched by podman should run rather then being launched by a rootless user.

Would it be possible to add a note that rootless Podman is not intended for production environments, and that podman run --userns=auto should be used instead?

[Luap99]

Saying rootless podman should not be used in production sounds wrong, I see no problem with doing this.

If you are just looking at a slirp4netns alternative you can look at pasta https://passt.top/passt/about/#pasta-pack-a-subtle-tap-abstraction, the maintainer want to integrate this into podman in the near future.

I don't understand the assumption that if we would write it from scratch that it would be more secure somehow.

[DemiMarie]

I don't understand the assumption that if we would write it from scratch that it would be more secure somehow.

The difference is the choice of programming language. C is a poor choice for this.

[DemiMarie]

If you are just looking at a slirp4netns alternative you can look at pasta https://passt.top/passt/about/#pasta-pack-a-subtle-tap-abstraction, the maintainer want to integrate this into podman in the near future.

There is a potential licensing problem. Google and many other companies won’t touch AGPL code.

[mheon]

If speed is a concern, https://github.com/rootless-containers/bypass4netns is an option - it's purely an extension of slirp but I've heard good things about its performance improvements.

[DemiMarie]

If speed is a concern, https://github.com/rootless-containers/bypass4netns is an option - it's purely an extension of slirp but I've heard good things about its performance improvements.

Looks like it has TOCTOU security problems. The only solution I can think of is for the bypass code to open the socket itself.