-
Notifications
You must be signed in to change notification settings - Fork 16
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
(RHEL-35665) CVE-2023-26604 systemd: privilege escalation via the less pager #153
Conversation
Some extra safety when invoked via "sudo". With this we address a genuine design flaw of sudo, and we shouldn't need to deal with this. But it's still a good idea to disable this surface given how exotic it is. Prompted by #5666 (cherry picked from commit 612ebf6) Related: RHEL-35665
…uested The variable is renamed to SYSTEMD_PAGERSECURE (because it's not just about less now), and we automatically enable secure mode in certain cases, but not otherwise. This approach is more nuanced, but should provide a better experience for users: - Previusly we would set LESSSECURE=1 and trust the pager to make use of it. But this has an effect only on less. We need to not start pagers which are insecure when in secure mode. In particular more is like that and is a very popular pager. - We don't enable secure mode always, which means that those other pagers can reasonably used. - We do the right thing by default, but the user has ultimate control by setting SYSTEMD_PAGERSECURE. Fixes #5666. v2: - also check $PKEXEC_UID v3: - use 'sd_pid_get_owner_uid() != geteuid()' as the condition Based on: 0a42426 rhel-only Resolves: RHEL-35665
Commit validationTracker - RHEL-35665 The following commits meet all requirements
Tracker validationSuccess🟢 Tracker RHEL-35665 has set desired product: Pull Request validationSuccess🟡 CI - Waived Auto MergeFailed🔴 Pull Request has unsupported target branch Success🟢 Pull Request is not marked as draft and it's not blocked by |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@mrc0mmand It seems that CentOS CI tests have passed, but the overall result is a failure. Could you please double-check? Thanks |
CentOS CI is FUBAR on C7, since C7 is no more (the fact that Duffy gave us a C9S machine in this case is a bug). And, unfortunately, I can't use the same trick as I did with the C8S job, as building C7 systemd on C9S is just impossible. So just ignore the CentOS CI results here; we'll have to rely on internal CI in this case. |
Resolves: RHEL-35665
Based on upstream commits but is rhel-only.