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.