Bug 1727382

Summary: Login to restricted acct fails
Product: Red Hat Enterprise Linux 8 Reporter: Steve Grubb <sgrubb>
Component: cockpitAssignee: Martin Pitt <mpitt>
Status: CLOSED ERRATA QA Contact: Jan Ščotka <jscotka>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 8.0Keywords: Rebase
Target Milestone: rc   
Target Release: 8.2   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-28 16:51:35 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1718814, 1727887, 1727902    
Bug Blocks: 1755139, 1761915    

Description Steve Grubb 2019-07-05 19:13:51 UTC
Description of problem:
When logging into an account that is not associated with selinux unconfined user/role, login fails. This may be a selinux policy issue or something else.



Version-Release number of selected component (if applicable):
cockpit-193-1.el8.x86_64
selinux-policy-targeted-3.14.3-4.el8.noarch

How reproducible:
always

Steps to Reproduce:
1. adduser unpriv
2. passwd unpriv
3. semanage login -a -s guest_u unpriv
4. Now login to the unpriv acct

Actual results:
Wrong user name or password

Expected results:
login

Additional info:
You can use -m to modify the association to change roles:
semanage login -m -s staff_u unpriv
semanage login -m -s sysadm_u unpriv
semanage login -m -s unconfined_u unpriv   <- this goes back to unconfined

Comment 1 Martin Pitt 2019-07-08 11:02:42 UTC
Thanks Steve, much appreciated!

Comment 2 Martin Pitt 2019-07-08 12:45:00 UTC
When I login as unprivileged user, several "interesting" things happen. First of all, the systemd user instance segfaults:

user: Main process exited, code=killed, status=11/SEGV
user: Failed with result 'protocol'.
Failed to start User Manager for UID 1002.

This is possibly related to this SELinux denial:

AVC avc:  denied  { signal } for  pid=17816 comm="systemd" scontext=guest_u:guest_r:guest_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=process permissive=0

(systemd should not segfault on that, though, but perhaps crash with ABRT or exit non-zero)

This leads to the user bus not being able to start up:

cockpit-bridge[17819]: dbus-daemon didn't send us a dbus address; not installed?

and finally, cockpit-bridge can't listen to a TCP socket:

AVC avc:  denied  { listen } for  pid=17819 comm="cockpit-bridge" laddr=127.0.0.1 lport=34295 scontext=guest_u:guest_r:guest_t:s0 tcontext=guest_u:guest_r:guest_t:s0 tclass=tcp_socket permissive=0
cockpit-bridge[17819]: couldn't bind and listen to local ipv4 socket: could not listen: Permission denied
cockpit-bridge[17819]: cockpit_packages_get_bridges: assertion 'packages != NULL' failed

and finally, cockpit isn't allowed to connect to polkit (but that shouldn't be fatal, it can also use sudo):

cockpit-bridge[17819]: couldn't get polkit authority: Error initializing authority: Could not connect: Permission denied

The systemd crash and the polkit failure are reproducible perfectly well with a ssh, I'll file bugs against selinux-policy and make this one depend on them.

I'll keep this bug for tracking the overall process and the addition of integration tests.

Comment 3 Martin Pitt 2019-07-08 13:10:23 UTC
I filed the systemd segfault as 1727895. This doesn't happen on RHEL 8.1, only on Fedora 30. But this is just a follow-up bug to 1727887, and should be mostly harmless.

Comment 4 Martin Pitt 2019-11-04 09:26:31 UTC
After some discussion and validation of the depending bugs, this now works well enough. I filed https://github.com/cockpit-project/cockpit/pull/13085 to add an automatic test case to ensure that this stays working.

Comment 8 errata-xmlrpc 2020-04-28 16:51:35 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1837