-
Notifications
You must be signed in to change notification settings - Fork 198
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-2905: passwd: create /etc/[g]shadow with mode 0 & unit: chmod /etc/[g]shadow[-] to 0000 #4911
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Because of how our composes work, we need to manually inject passwd-related things before installing packages. A somewhat recent regression in that area made it so that the `/etc/shadow` and `/etc/gshadow` files were created with default permissions (0644), which meant they were world readable. Fix this by explicitly setting their modes to 0. Ideally, we would rely on the canonical permissions set in the `setup` package here, but it's tricky to fix that without reworking how we install `setup` and handle `passwd` treefile options. Fixes fdb879c ("passwd: sync `etc/{,g}shadow` according to `etc/{passwd,group}`"). Fixes coreos#4401
fdb879c introduced a regression where /etc/[g]shadow[-] files where created with default permissions: 0644 This unit chmods /etc/shadow, /etc/gshadow and backup copies to 0000 before interactive login is allowed on a system. This will fix the systems that were deployed with the above issue. We keep the stamp in /etc to account for the case where a deployment with this unit is rolled back. If we used /var, the stamp would have stayed but the fix would not be re-applied on the next update.
cgwalters
approved these changes
Apr 9, 2024
travier
added a commit
to travier/fedora-coreos-config
that referenced
this pull request
Apr 9, 2024
Merge with the existing passwd & group check and also check backup files. See: coreos/rpm-ostree#4911
dustymabe
pushed a commit
to coreosbot-releng/fedora-coreos-config
that referenced
this pull request
Apr 9, 2024
Merge with the existing passwd & group check and also check backup files. See: coreos/rpm-ostree#4911
dustymabe
pushed a commit
to coreosbot-releng/fedora-coreos-config
that referenced
this pull request
Apr 9, 2024
Merge with the existing passwd & group check and also check backup files. See: coreos/rpm-ostree#4911
champtar
reviewed
Apr 9, 2024
dustymabe
pushed a commit
to coreos/fedora-coreos-config
that referenced
this pull request
Apr 9, 2024
Merge with the existing passwd & group check and also check backup files. See: coreos/rpm-ostree#4911
dustymabe
pushed a commit
to coreos/fedora-coreos-config
that referenced
this pull request
Apr 9, 2024
Merge with the existing passwd & group check and also check backup files. See: coreos/rpm-ostree#4911
travier
added a commit
to travier/rpm-ostree
that referenced
this pull request
Apr 12, 2024
The fix in coreos#4911 for CVE-2024-2905 only fixes the permissions for the current deployment and not for previous deployments for existing installations. The affected files can still be read from the previous deployment by looking at them in `/sysroot/ostree/deploy/...`. Extend the unit to fix all deployments on the system and update the logic to only update files that exists. See: coreos#4911 See: GHSA-2m76-cwhg-7wv6 See: ostreedev/ostree#3211
travier
added a commit
to travier/rpm-ostree
that referenced
this pull request
Apr 12, 2024
The fix in coreos#4911 for CVE-2024-2905 only fixes the permissions for the current deployment and not for previous deployments for existing installations. The affected files can still be read from the previous deployment by looking at them in `/sysroot/ostree/deploy/...`. Extend the logic to fix all deployments on the system and update the logic to only update files that exists. See: coreos#4911 See: GHSA-2m76-cwhg-7wv6 See: ostreedev/ostree#3211
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
passwd: create
/etc/[g]shadow
with mode 0Because of how our composes work, we need to manually inject
passwd-related things before installing packages. A somewhat recent
regression in that area made it so that the
/etc/shadow
and/etc/gshadow
files were created with default permissions (0644), whichmeant they were world readable.
Fix this by explicitly setting their modes to 0. Ideally, we would rely
on the canonical permissions set in the
setup
package here, but it'stricky to fix that without reworking how we install
setup
and handlepasswd
treefile options.Fixes fdb879c ("passwd: sync
etc/{,g}shadow
according toetc/{passwd,group}
").Fixes #4401
unit: chmod /etc/[g]shadow[-] to 0000
fdb879c introduced a regression where /etc/[g]shadow[-] files where
created with default permissions: 0644
This unit chmods /etc/shadow, /etc/gshadow and backup copies to 0000
before interactive login is allowed on a system.
This will fix the systems that were deployed with the above issue.
We keep the stamp in /etc to account for the case where a deployment
with this unit is rolled back. If we used /var, the stamp would have
stayed but the fix would not be re-applied on the next update.
This fixes CVE-2024-2905. Advisory to be published soon.