Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2024-1753 fix for main + pasta setup changes #22079

Merged

Conversation

TomSweeneyRedHat
Copy link
Member

Bump to the version of Buidah in its main branch to get the CVE-2024-1753 fix.

[NO NEW TESTS NEEDED]

Does this PR introduce a user-facing change?

None

Bump to the version of Buidah in it's main branch to get the
CVE-2024-1753 fix.

[NO NEW TESTS NEEDED]

Signed-off-by: tomsweeneyredhat <[email protected]>
@openshift-ci openshift-ci bot added release-note-none approved Indicates a PR has been approved by an approver from all required OWNERS files. labels Mar 18, 2024
@TomSweeneyRedHat
Copy link
Member Author

I will say I was not expecting Buildah to report itself as 1.35.1-#, rather, I thought it would be 1.35.0-# or perhaps 1.36.0-dev-* which is the version in the top of main.

Copy link

Cockpit tests failed for commit 079bfb0. @martinpitt, @jelly, @mvollmer please check.

@Luap99
Copy link
Member

Luap99 commented Mar 19, 2024

I will say I was not expecting Buildah to report itself as 1.35.1-#, rather, I thought it would be 1.35.0-# or perhaps 1.36.0-dev-* which is the version in the top of main.

yeah that is normal, the go logic to determine the version is not perfect so it can guess things wrong, in any case the version doesn't mean anything as we would still not not from when the vendor really is. Really the interesting part to figure out what is being vendored is the -xxxx git commit suffix after the fake version.

@Luap99
Copy link
Member

Luap99 commented Mar 19, 2024

Looking at the test failures I think my pasta changes in c/common caused them, I guess given you already vendored the required changes I need I could just push my fix commits to this PR here to avoid duplicate vendoring work.

Luap99 added 2 commits March 19, 2024 12:09
By default we just ignored any localhost reolvers, this is problematic
for anyone with more complicated dns setups, i.e. split dns with
systemd-reolved. To address this we now make use of the build in dns
proxy in pasta. As such we need to set the default nameserver ip now.

A second change is the option to exclude certain ips when generating the
host.containers.internal ip. With that we no longer set it to the same
ip as is used in the netns. The fix is not perfect as it could mean on a
system with a single ip we no longer add the entry, however given the
previous entry was incorrect anyway this seems like the better behavior.

Fixes containers#22044

Signed-off-by: Paul Holzinger <[email protected]>
Always teardown the network, trying to reuse the netns has caused
a significant amount of bugs in this code here. It also never worked
for containers with user namespaces. So once and for all simplify this
by never reusing the netns. Originally this was done to have a faster
restart of containers but with netavark now we are much faster so it
shouldn't be that noticeable in practice. It also makes more sense to
reconfigure the netns as it is likely that the container exited due
some broken network state in which case reusing would just cause more
harm than good.

The main motivation for this change was the pasta change to use
--dns-forward by default. As the restarted contianer had no idea what
nameserver to use as pasta just kept running.

Signed-off-by: Paul Holzinger <[email protected]>
@Luap99 Luap99 changed the title CVE-2024-1753 fix for main CVE-2024-1753 fix for main + pasta setup changes Mar 19, 2024
@Luap99
Copy link
Member

Luap99 commented Mar 19, 2024

@mheon PTAL at my pasta changes, as we discussed I also removed the netns reuse logic in the restart case.

Copy link

Cockpit tests failed for commit 15b8bb7. @martinpitt, @jelly, @mvollmer please check.

@mheon
Copy link
Member

mheon commented Mar 19, 2024

Sure, LGTM

@TomSweeneyRedHat
Copy link
Member Author

Thanks @Luap99 Rawhide appears to be the only test hanging, and I think that's expected. @mheon, can this be merged?

@mheon
Copy link
Member

mheon commented Mar 19, 2024 via email

Copy link
Member

@Luap99 Luap99 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Mar 20, 2024
Copy link
Contributor

openshift-ci bot commented Mar 20, 2024

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Luap99, TomSweeneyRedHat

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:
  • OWNERS [Luap99,TomSweeneyRedHat]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-merge-bot openshift-merge-bot bot merged commit e5059fc into containers:main Mar 20, 2024
93 of 94 checks passed
@stale-locking-app stale-locking-app bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Jun 19, 2024
@stale-locking-app stale-locking-app bot locked as resolved and limited conversation to collaborators Jun 19, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. release-note-none
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants