Pasta networking is not supported for rootless containers created by root with --userns=auto #17840
Comments
|
Hi @lukasmrtvy, thanks for reporting this!
In some sense this is intended: pasta won't run as root because that would unnecessarily broaden privileges that can be used after exploiting an attack vector, and I didn't expect it to be particularly useful if Podman is anyway started as root. It was a bit tricky (albeit doable) to safely handle the switch to a fallback unprivileged user when started by Podman, so we skipped that in the initial integration. However, I guess it might be useful regardless of security considerations if you want a particular network configuration or if you just have some other reasons to run Podman as root for the moment. It would be interesting if you could share your use case. Regardless of that, yes, I would still consider it as a missing feature. Cc: @Luap99 |
|
What is the use case here? As root it seems much more preferable to just use the kernel networking tools (bridge + veth pair or macvlan) as those should be much more performant. |
Well, one might still want network isolation (against spoofing, packet forging, etc.), and throughput is usually higher for local port forwarding compared to building frames for veth or macvlan. But I'm also really curious to hear the use case here. :) |
|
I need to control nftables for rootless containers and that's not possible. It works ok in rootful with @sbrivio-rh mentioned https://superuser.com/questions/1277697/making-routing-decisions-based-on-uid-using-nftables, but not sure if this would work. Rootless container with slirp4netns / pasta with |
|
@Luap99, you can assign this one to me, unless you plan to work on it as part of anything else you have pending. |
Luap99
added
kind/feature
|
A friendly reminder that this issue had no activity for 30 days. |
|
@sbrivio-rh Any progress? |
No, sorry, not yet. It's a quite a low priority item on my list (but we're talking about weeks, not months). |
|
A friendly reminder that this issue had no activity for 30 days. |
|
cc @dgibson |
@lukasmrtvy I'm trying to understand this requirement a bit better. I'm assuming what you're doing here is modifying nftables rules in the host which will affect packets flowing to or from your container. Is that correct? What exactly do those rules look like? Just being able to invoke pasta when root may not be enough here. Because pasta is forwarding traffic at L4, rather than L2, the rules you'd need to match them in the host may well be different from those you'd need for bridge based networking, and I doubt that's something we could practically address in podman or pasta. |
|
We are hitting the pasta-blocked-as-root issue in a nested container scenario: a rootless podman instance needs[1] to run sub-containers with rootful podman, and in some situations these sub-containers need network isolation. Previously we have used slirp4netns (which somewhat confusingly is not blocked) but that has some reliability issues so we're looking to switch to pasta in this setup. As a workaround, commenting out the rootless check for pasta seems to work—the attack surface issue is not super important here as the requirement is mainly a glorified chroot. [1] Technically the top-level container container could run its sub-containers as a non-root user, but it's running a somewhat exotic CI agent that makes this even more painful than maintaining a patched podman binary. |
|
@vuori I'm a little surprising by this case. pasta can run as "root" (mapped UID 0) within a namespace / container - it at least attempts to only prevent running as "real", unmapped root. What does your exact stack of nested containers look like? |
|
pasta itself runs fine, it's just that pkg/specgen/namespaces.go:validateNetNS actively prevents |
Ah, that makes sense. @Luap99 any thoughts? |
|
pasta is launched from the podman context not from the container context as such the userns is entirely ignored and doesn't chnage anything compared to a container with --userns. Sure we could try to make that work but then it will still not work for non userns root containers. So the better question is why does pasta refuses to run as root and drops privileges before opening the netns path/configuring the interfaces? If pasta would not switch to nobody it should just work. |
Ok, but for the nested containers, described here, the inner podman's context should already be in the userns established by the outer podman. So I'd still expect pasta to be invoked inside a userns, and therefore run, even as UID 0.
This is intended to stop the user from shooting themselves in the foot by running pasta privileged - and therefore compromising the security and isolation that pasta is intended to give. |
|
Yeah, to re-iterate, the block is completely on podman side and if the root check in podman code is removed pasta itself works fine. The comments indicate that this is some kind of security footgun prevention. slirp4netns is allowed by podman in privileged mode, does pasta have somehow different security properties when being run as root? |
I haven't looked into this recently, but the main reason why I added that check is that, back then, pasta wouldn't work when Podman started it as root. Fixes such as this one and possibly more were needed. Now it should work... and it works, as you reported. By the way, from #17840 (comment):
But now I guess we can drop the check in validateNetNS().
No, not really. It will run as |
Except it doesn't work when running as real root, it only works when already inside a nested userns. This is what I mean by pasta is refusing to run as root and this isn't something podman can fix. And yes I rather check this in podman and return a useful error to users rather than the pasta error which most users have no idea about why this happens. But sure we can fix the validate check in podman to correctly check for in userns and not is uid 0.
Sure but switching to nobody also means running pasta as root is completely non functional as you cannot ever pass a netns owned by root. I run into the same issue elsewhere, containers/aardvark-dns#499, just in tests so I do not care that much about the security concerns in that case. |
pasta doesn't switch to nobody when we already run in a userns so we can use it there. The unshare package checks the same condition and returns true even if uid 0 in this case so we can directly call this. ref containers#17840 (comment) Signed-off-by: Paul Holzinger <[email protected]>
pasta doesn't switch to nobody when we already run in a userns so we can use it there. The unshare package checks the same condition and returns true even if uid 0 in this case so we can directly call this. ref containers#17840 (comment) Signed-off-by: Paul Holzinger <[email protected]>
Ouch, sorry, you're right. And this is actually what this ticket was about, originally.
Right, and it's a bit silly to force users to use "root" networking because we want to avoid running pasta as root. It makes no sense in terms of overall security.
We can try something else though (as you perhaps were suggesting in #17840 (comment)): we could defer switching to I think what's most relevant is that we avoid running the main loop as root, but the setup phase isn't really affected by untrusted input. I'll work on that and report back. In the short term, I still think that your #23961 makes sense nevertheless (it might take me a while to make that change in pasta). |
I haven't looked how you do in pasta today but I guess one reason for the user is to drop all capabilities? In this case the thing to consider is that you would need to keep some caps, i.e. CAP_NET_BIND_SERVICE when using auto port forward to allow binding < 1024. And AFAIK you have been talking about a netlink monitor mode to update the addresses in the namespace during runtime so then you would need to keep CAP_NET_ADMIN as well. Of course we can switch users and keep caps but it is a bit more work to do so I think. |
Ah. yes. I was thinking specifically of @vuori's situation, not the one originally described by @lukasmrtvy. |
|
The PR makes pasta work at least in my nested scenario. Thanks for the fix. |
We also drop most capabilities explicitly if present, but yes, that's the reason. However, we can't rely on capabilities alone to restrict our privileges because 1. there are still a number of checks in the kernel relying on the user having UID 0 (at least in a given namespace) instead of looking at actual capabilities and 2. if we run as root, we can open root-accessible files. We remount the root filesystem from an empty one, but if something goes wrong with that, it's nice to avoid running as root.
Right, we keep it if given, both outside and inside the target namespace.
Yes, I'm working on that, and yes, we already keep CAP_NET_ADMIN in the target namespace.
No no it's all there already. But for the original issue reported here, we need to drop root a bit later so that we can join the target namespace when we start. |
|
But the outside/inside logic only applies when a userns is created because caps are per user namespace only. |
pasta doesn't switch to nobody when we already run in a userns so we can use it there. The unshare package checks the same condition and returns true even if uid 0 in this case so we can directly call this. ref containers#17840 (comment) Signed-off-by: Paul Holzinger <[email protected]>
pasta doesn't switch to nobody when we already run in a userns so we can use it there. The unshare package checks the same condition and returns true even if uid 0 in this case so we can directly call this. ref containers#17840 (comment) Signed-off-by: Paul Holzinger <[email protected]>
Issue Description
Pasta networking is not supported for rootless containers created by root with --userns=auto
Steps to reproduce the issue
Steps to reproduce the issue
sudo supodman run --rm -it --userns=auto --network pasta alpineDescribe the results you received
Error: invalid config provided: pasta networking is only supported for rootless modeDescribe the results you expected
Rootless container is created with pasta networking
podman info output
Podman in a container
No
Privileged Or Rootless
None
Upstream Latest Release
Yes
Additional environment details
Additional environment details
Additional information
Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting
The text was updated successfully, but these errors were encountered: