Source IP always 127.0.0.1 in rootless Podman 1.8.0 #5138
Comments
openshift-ci-robot
added
the
kind/bug
|
This may be a side-effect of the swap to RootlessKit for port forwarding - @AkihiroSuda PTAL |
|
Intentional #4586 (comment) |
|
Ah, I missed this was an intentional change. While I do see the benefits of the new solution, I'm wondering if we are losing something valuable. Just for context, this change broke two setups I run with rootless Podman for local development/testing:
Since AFAIK rootless Podman has no network support, even container connections need to go through exposed ports, effectively making all traffic local. Any use-cases that cover either security or audibility relying on source IP will no longer be possible in rootless Podman. It can also change the behavior of containers running as root or rootless. Since the incoming connections now arrive in on the loopback interface instead of the container's virtual interface. The process is required to listen on the loopback interface and may have different (security) policies there. |
|
Thanks for the context and sorry. |
|
@AkihiroSuda we could probably add another network type:
What do you think? |
|
That may give people false sense that slirp4netns was not used at all when |
|
Also, in future, rootlesskit MAY implement built-in slirp functionality using slirpnetstack as a Go library if there is a demand. I think |
wouldn't that be an implementation detail for users? So if that is the case, should we have |
|
Yes, I would go along with @giuseppe Just use slirp4netns or rootlesskit. We can document the difference, most users will have no idea the difference,and will just go with whatever the distro or podman chooses as the default. |
|
i unfortunately ran into this today (using centos 7).. looked at the but alas doesn't like it: @AkihiroSuda @giuseppe @rhatdan so what actually is the right way/options to switch and be able to revert away from the default of using rootlesskit optimization (for example, i need the source address more than i need 27gbps and the 8gbps bandwidth using slirp4netns is more than sufficient for my use-case :-) i also can't work-around this by using |
|
I am just worried on the configuration side and have to maintain two different backends for minimal differences. Would you like to open a PR to address it? We need to take pieces from da7595a that were removed and make it configurable. We accept What do you think? |
|
i tried it's my understanding that slirp4netns is the "traditional" way of doing rootless networking, and as of da7595a it defaults to rootlesskitport for rootless port forwarding.. so why does also i'm unclear what the two values on either side of the colon are in |
it won't change anything in the current version since We'd need to add back the support for listening through slirp4netns, and I was thinking of a way to expose it to users. |
|
Ahh thanks for the explanation, so there's two components in play here.. setting up the networking capabilities for the rootless container AND doing port-forwarding.. slirp4netns can do both, but as of da7595a it only does the former, and the latter has been defaulted since 1.8.0 to be done by rootlessport, where the source always is 127.0.0.1 (any reason why?).. is that summary correct/accurate? As for the PR to re-enable the ability to choose, the colon notation lets you pick the two different parts.. Were you asking for me to create this PR or for someone else (such as @AkihiroSuda ?).. me i can give it the old college-try, but go is not my language of preference (i'm more of a pythonista) |
at the moment I've no time to look at it, but if you could give it a try and get to a point where we have both methods living in the code base (i.e. recover the existing method from da7595a) I could help with the remaining plumbing and have something faster. Also please use the v1.9 stable branch as the base for development. |
…irp4netns As of podman 1.8.0, because of commit da7595a, the default approach of providing port-forwarding in rootless mode has switched (and been hard-coded) to rootlessport, for the purpose of providing super performance. The side-effect of this switch is source within the container to the port-forwarded service always appears to originate from 127.0.0.1 (see issue containers#5138). This commit allows a user to specify if they want to revert to the previous approach of leveraging slirp4netns add_hostfwd() api which, although not as stellar performance, restores usefulness of seeing incoming traffic origin IP addresses. The change should be transparent; when not specified, rootlessport will continue to be used, however if specifying --net slirp4netns:slirplisten the old approach will be used. Note: the above may imply the restored port-forwarding via slirp4netns is not as performant as the new rootlessport approach, however the figures shared in the original commit that introduced rootlessport are as follows: slirp4netns: 8.3 Gbps, RootlessKit: 27.3 Gbps, which are more than sufficient for many use cases where the origin of traffic is more important than limits that cannot be reached due to bottlenecks elsewhere.
…irp4netns As of podman 1.8.0, because of commit da7595a, the default approach of providing port-forwarding in rootless mode has switched (and been hard-coded) to rootlessport, for the purpose of providing super performance. The side-effect of this switch is source within the container to the port-forwarded service always appears to originate from 127.0.0.1 (see issue containers#5138). This commit allows a user to specify if they want to revert to the previous approach of leveraging slirp4netns add_hostfwd() api which, although not as stellar performance, restores usefulness of seeing incoming traffic origin IP addresses. The change should be transparent; when not specified, rootlessport will continue to be used, however if specifying --net slirp4netns:slirplisten the old approach will be used. Note: the above may imply the restored port-forwarding via slirp4netns is not as performant as the new rootlessport approach, however the figures shared in the original commit that introduced rootlessport are as follows: slirp4netns: 8.3 Gbps, RootlessKit: 27.3 Gbps, which are more than sufficient for many use cases where the origin of traffic is more important than limits that cannot be reached due to bottlenecks elsewhere.
…netns As of podman 1.8.0, because of commit da7595a, the default approach of providing port-forwarding in rootless mode has switched (and been hard-coded) to rootlessport, for the purpose of providing super performance. The side-effect of this switch is source within the container to the port-forwarded service always appears to originate from 127.0.0.1 (see issue containers#5138). This commit allows a user to specify if they want to revert to the previous approach of leveraging slirp4netns add_hostfwd() api which, although not as stellar performance, restores usefulness of seeing incoming traffic origin IP addresses. The change should be transparent; when not specified, rootlessport will continue to be used, however if specifying --net slirp4netns:slirplisten the old approach will be used. Note: the above may imply the restored port-forwarding via slirp4netns is not as performant as the new rootlessport approach, however the figures shared in the original commit that introduced rootlessport are as follows: slirp4netns: 8.3 Gbps, RootlessKit: 27.3 Gbps, which are more than sufficient for many use cases where the origin of traffic is more important than limits that cannot be reached due to bottlenecks elsewhere. Signed-off-by: Aleks Mariusz <m.k@alek.cx>
…netns As of podman 1.8.0, because of commit da7595a, the default approach of providing port-forwarding in rootless mode has switched (and been hard-coded) to rootlessport, for the purpose of providing super performance. The side-effect of this switch is source within the container to the port-forwarded service always appears to originate from 127.0.0.1 (see issue containers#5138). This commit allows a user to specify if they want to revert to the previous approach of leveraging slirp4netns add_hostfwd() api which, although not as stellar performance, restores usefulness of seeing incoming traffic origin IP addresses. The change should be transparent; when not specified, rootlessport will continue to be used, however if specifying --net slirp4netns:slirplisten the old approach will be used. Note: the above may imply the restored port-forwarding via slirp4netns is not as performant as the new rootlessport approach, however the figures shared in the original commit that introduced rootlessport are as follows: slirp4netns: 8.3 Gbps, RootlessKit: 27.3 Gbps, which are more than sufficient for many use cases where the origin of traffic is more important than limits that cannot be reached due to bottlenecks elsewhere. Signed-off-by: Aleks Mariusz <m.k@alek.cx>
…netns As of podman 1.8.0, because of commit da7595a, the default approach of providing port-forwarding in rootless mode has switched (and been hard-coded) to rootlessport, for the purpose of providing super performance. The side-effect of this switch is source within the container to the port-forwarded service always appears to originate from 127.0.0.1 (see issue containers#5138). This commit allows a user to specify if they want to revert to the previous approach of leveraging slirp4netns add_hostfwd() api which, although not as stellar performance, restores usefulness of seeing incoming traffic origin IP addresses. The change should be transparent; when not specified, rootlessport will continue to be used, however if specifying --net slirp4netns:slirplisten the old approach will be used. Note: the above may imply the restored port-forwarding via slirp4netns is not as performant as the new rootlessport approach, however the figures shared in the original commit that introduced rootlessport are as follows: slirp4netns: 8.3 Gbps, RootlessKit: 27.3 Gbps, which are more than sufficient for many use cases where the origin of traffic is more important than limits that cannot be reached due to bottlenecks elsewhere. Signed-off-by: Aleks Mariusz <m.k@alek.cx>
|
+1 this broke two of my setups as well also I find it very strange to see 127.0.0.1 as source IP for exposed ports |
|
i think all users expect that the source IP is the real source ip even in rootless mode |
|
I think that's a little hyperbolic - while we've seen complaints about the switch to rootlesskit port forwarder, for the most part it doesn't seem to have been a problem for our users. We have no plans to revert the change of port forwarder, but @aleks-mariusz is working on a PR to allow optionally selecting the old port forwarding method for containers where the new approach does prove problematic. |
|
may be ;-) at least i'm thinking of log files where remote ip is logged. I already tried the PR but src IP is still 127.0.0.1 - commented in the PR |
As of podman 1.8.0, because of commit da7595a, the default approach of providing port-forwarding in rootless mode has switched (and been hard-coded) to rootlessport, for the purpose of providing super performance. The side-effect of this switch is source within the container to the port-forwarded service always appears to originate from 127.0.0.1 (see issue containers#5138). This commit allows a user to specify if they want to revert to the previous approach of leveraging slirp4netns add_hostfwd() api which, although not as stellar performance, restores usefulness of seeing incoming traffic origin IP addresses. The change should be transparent; when not specified, rootlessport will continue to be used, however if specifying --net slirp4netns:slirplisten the old approach will be used. Note: the above may imply the restored port-forwarding via slirp4netns is not as performant as the new rootlessport approach, however the figures shared in the original commit that introduced rootlessport are as follows: slirp4netns: 8.3 Gbps, RootlessKit: 27.3 Gbps, which are more than sufficient for many use cases where the origin of traffic is more important than limits that cannot be reached due to bottlenecks elsewhere. Signed-off-by: Aleks Mariusz <m.k@alek.cx>
As of podman 1.8.0, because of commit da7595a, the default approach of providing port-forwarding in rootless mode has switched (and been hard-coded) to rootlessport, for the purpose of providing super performance. The side-effect of this switch is source within the container to the port-forwarded service always appears to originate from 127.0.0.1 (see issue containers#5138). This commit allows a user to specify if they want to revert to the previous approach of leveraging slirp4netns add_hostfwd() api which, although not as stellar performance, restores usefulness of seeing incoming traffic origin IP addresses. The change should be transparent; when not specified, rootlessport will continue to be used, however if specifying --net slirp4netns:slirplisten the old approach will be used. Note: the above may imply the restored port-forwarding via slirp4netns is not as performant as the new rootlessport approach, however the figures shared in the original commit that introduced rootlessport are as follows: slirp4netns: 8.3 Gbps, RootlessKit: 27.3 Gbps, which are more than sufficient for many use cases where the origin of traffic is more important than limits that cannot be reached due to bottlenecks elsewhere. Signed-off-by: Aleks Mariusz <m.k@alek.cx>
As of podman 1.8.0, because of commit da7595a, the default approach of providing port-forwarding in rootless mode has switched (and been hard-coded) to rootlessport, for the purpose of providing super performance. The side-effect of this switch is source within the container to the port-forwarded service always appears to originate from 127.0.0.1 (see issue containers#5138). This commit allows a user to specify if they want to revert to the previous approach of leveraging slirp4netns add_hostfwd() api which, although not as stellar performance, restores usefulness of seeing incoming traffic origin IP addresses. The change should be transparent; when not specified, rootlessport will continue to be used, however if specifying --net slirp4netns:slirplisten the old approach will be used. Note: the above may imply the restored port-forwarding via slirp4netns is not as performant as the new rootlessport approach, however the figures shared in the original commit that introduced rootlessport are as follows: slirp4netns: 8.3 Gbps, RootlessKit: 27.3 Gbps, which are more than sufficient for many use cases where the origin of traffic is more important than limits that cannot be reached due to bottlenecks elsewhere. Signed-off-by: Aleks Mariusz <m.k@alek.cx> Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
As of podman 1.8.0, because of commit da7595a, the default approach of providing port-forwarding in rootless mode has switched (and been hard-coded) to rootlessport, for the purpose of providing super performance. The side-effect of this switch is source within the container to the port-forwarded service always appears to originate from 127.0.0.1 (see issue containers#5138). This commit allows a user to specify if they want to revert to the previous approach of leveraging slirp4netns add_hostfwd() api which, although not as stellar performance, restores usefulness of seeing incoming traffic origin IP addresses. The change should be transparent; when not specified, rootlessport will continue to be used, however if specifying --net slirp4netns:slirplisten the old approach will be used. Note: the above may imply the restored port-forwarding via slirp4netns is not as performant as the new rootlessport approach, however the figures shared in the original commit that introduced rootlessport are as follows: slirp4netns: 8.3 Gbps, RootlessKit: 27.3 Gbps, which are more than sufficient for many use cases where the origin of traffic is more important than limits that cannot be reached due to bottlenecks elsewhere. Signed-off-by: Aleks Mariusz <m.k@alek.cx> Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
|
update: this will be fixed thanks to #6965 being merged, either by building from master or waiting until the next release where this PR is picked up - you'll want to adding parameter |
|
I want to note that this also has a security implication. PostgreSQL (via the library/postgres image) by default regards all local connections as trusted. This means that anyone can connect to the database when Podman is operating under the rootless mode with default options. |
|
That sounds like an issue on Postgres side. Connections from localhost should never be trusted. https://cathyjf.com/articles/local-servers-can-get-you-compromised |
set the source IP to the slirp4netns address instead of 127.0.0.1 when using rootlesskit. Closes: containers#5138 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
|
opened a PR to address this issue: #9052 |
set the source IP to the slirp4netns address instead of 127.0.0.1 when using rootlesskit. Closes: containers#5138 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
set the source IP to the slirp4netns address instead of 127.0.0.1 when using rootlesskit. Closes: containers#5138 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
set the source IP to the slirp4netns address instead of 127.0.0.1 when using rootlesskit. Closes: containers#5138 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
set the source IP to the slirp4netns address instead of 127.0.0.1 when using rootlesskit. Closes: containers#5138 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
set the source IP to the slirp4netns address instead of 127.0.0.1 when using rootlesskit. Closes: containers#5138 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
set the source IP to the slirp4netns address instead of 127.0.0.1 when using rootlesskit. Closes: containers#5138 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
set the source IP to the slirp4netns address instead of 127.0.0.1 when using rootlesskit. Closes: containers#5138 Fixes RHBZ#1922866 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
set the source IP to the slirp4netns address instead of 127.0.0.1 when using rootlesskit. Closes: containers#5138 Fixes RHBZ#1922866 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
set the source IP to the slirp4netns address instead of 127.0.0.1 when using rootlesskit. Closes: containers#5138 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
This requires rebuilding pod. Thanks to @nhlpl for reporting problem with all logins seen from the same IP. Also see: containers/podman#5138 (comment)
- podman configures the source IP of external connections to 10.0.2.100 since podman 3.0.0, hence binding to 127.0.0.1 will stop working. See: CVE-2021-20199 mentioned in https://github.com/containers/podman/releases/tag/v3.0.0 mheon/libpod@5172cfe containers/podman#5138
github-actions
bot
added
the
locked - please file new issue/PR
/kind bug
Description
For a rootless container the source IP of incoming packets on a publish port is always
127.0.0.1. Even if the request is made from an external host.Steps to reproduce the issue:
Describe the results you received:
The logged source address is always 127.0.0.1
Describe the results you expected:
The logged source ip address to match the ip of the host the request was coming from.
Additional information you deem important (e.g. issue happens only occasionally):
In Podman 1.7 this worked as expected. And it's probably related to:
Output of
podman version:Output of
podman info --debug:Package info (e.g. output of
rpm -q podmanorapt list podman):Additional environment details (AWS, VirtualBox, physical, etc.):
Silverblue 31.20200209.0 (Workstation Edition)
The text was updated successfully, but these errors were encountered: