Description of problem: In cockpit the bridge uses socketpair() to communicate to subprocesses, also with sudo (sudo cockpit-bridge is the thing that executes administrative commands). But this only works for unconfined users, not sysadm_u or staff_u roles. The general problem area is the same as bug 1814052 ("user_u and staff_u users cannot read memfds from cockpit-session"), but as it affects different roles, it's not the same bug. But it shares the same difficulty with debugging it, as there is again absolutely no audit logging about SELinux replacing fds with /dev/null. Version-Release number of selected component (if applicable): selinux-policy-3.14.4-49.fc31.noarch sudo-1.9.0-0.1.b1.fc31.x86_64 How reproducible: Always Steps to Reproduce: 1. Create an "admin" user in wheel group, so that they can sudo 2. Assign it to a restricted role: # semanage login -a -s staff_u admin 3. Allow sudo without password (this is not what happens for cockpit of course, but it severely simplifies the reproducer): # echo "admin ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers 4. Log in as admin, and verify that plain sudo works: $ sudo whoami root 5. Try sudo through a socketpair: $ python3 -c 'import socket, subprocess; r = socket.socketpair(); p = subprocess.Popen(["sudo", "whoami"], stdout=r[0]); print(p.wait()); print(r[1].recv(100))' Actual results: sudo succeeds (you see a "0" printed from p.wait), but the recv() hangs, as there is no data. Expected results: recv() receives stdout, i. e. b"root\n". This does work with `setenforce 0` or as unrestricted user. I'd also expect to get an audit denial log if SELinux replaces file descriptor, as this is otherwise impossible to debug, or adjust the policy (see bug 1814052) Additional info: The same happens with `sysadm_u`, but due to bug 1814549 ssh is broken for sysadm_u. You can still run the reproducer when logging into the test VM on the console (like `virsh console`), or on your host OS. But with staff_u it's easier as ssh works.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Reopening, this is still the case on Fedora 34.
I believe this issue should be addressed by the following commits group: https://github.com/fedora-selinux/selinux-policy/pull/976
So actually one more commit is required even with selinux-policy-35.8-1.fc35.noarch.rpm: https://github.com/fedora-selinux/selinux-policy/pull/985 Martin, what makes it hard to troubleshoot are dontaudit rules. They can be disabled with # semodule -DB Additionally, I suppose running sudo with "-r staff_r" would help, too.
Thanks Zdenek for the -DB trick! That's mighty helpful.
(In reply to Martin Pitt from comment #6) > Thanks Zdenek for the -DB trick! That's mighty helpful. Surely additional knowledge is required to triage the denials. As it may flood logs easily, there is another command to learn to enable dontaudit rules again: # semodule -B
FEDORA-2022-8e1e2c866c has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2022-8e1e2c866c
FEDORA-2022-8e1e2c866c has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-8e1e2c866c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-8e1e2c866c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-8e1e2c866c has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.