Hide Forgot
Description of problem: One goal for RHEL 8.2 is Cockpit support for smart card (i. e. client TLS certificate) authentication, see bug 1678465. For that we needed to completely rewrite and harden cockpit's web server TLS handling. This requires some adjustments to the SELinux policy. I think we are now at the point were we have everything that we need. Can you please sync cockpit.{te,fc,if} to at least this commit: https://github.com/fedora-selinux/selinux-policy-contrib/commit/25fca172055f If you rather want to cherry-pick than sync, we need these commits: https://github.com/fedora-selinux/selinux-policy-contrib/commit/e5631ccdd2 https://github.com/fedora-selinux/selinux-policy-contrib/commit/819c407b8744 https://github.com/fedora-selinux/selinux-policy-contrib/commit/43968483ee1 https://github.com/fedora-selinux/selinux-policy-contrib/commit/79370855918 https://github.com/fedora-selinux/selinux-policy-contrib/commit/49d1174326 https://github.com/fedora-selinux/selinux-policy-contrib/commit/25fca172055f Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Try and run latest cockpit (206) on RHEL 8.2. The .spec has a hack in %post that extends the SELinux policy to the above, but we shouldn't ship that in the production release. I'm happy to validate an update, I can easily do that with our testsuite.
Validation: 1. I built a RHEL 8.2 image from current nightlies (with virt-install), containing the *previous* selinux-policy 3.14.3-29.el8. 2. I then installed cockpit-ws its %post hack dropped, i. e. no local SELinux hacking any more. 3. This ends up with /usr/libexec/cockpit-tls and /usr/libexec/cockpit-wsinstance-factory having the wrong type "bin_t". 4. I start cockpit, and surprisingly it *works* -- there are no SELinux violations. ("getenforce" confirms that it's on). On second thought this makes sense, as cockpit-tls (the top-level process) would just run basically unconfined: # ps auxZ | grep cockpit system_u:system_r:unconfined_service_t:s0 cockpit+ 1217 1.0 0.5 549128 4740 ? Ssl 15:38 0:00 /usr/libexec/cockpit-tls system_u:system_r:cockpit_ws_t:s0 cockpit+ 1223 2.2 1.1 532728 10044 ? Ssl 15:38 0:00 /usr/libexec/cockpit-ws --for-tls-proxy --port=0 system_u:system_r:cockpit_session_t:s0 root 1234 0.1 0.8 143592 7160 ? S 15:38 0:00 /usr/libexec/cockpit-session localhost 5. I grabbed 3.14.3-30 rpms from https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=1038370 (they are not in nightly compose yet), rpm -U'ed them, and confirm that the types are now correct: /usr/libexec/cockpit-tls and /usr/libexec/cockpit-wsinstance-factory are now cockpit_ws_exec_t. 6. I rebooted, and confirm that I can still log into cockpit. cockpit-tls is now correctly confined: system_u:system_r:cockpit_ws_t:s0 cockpit+ 1142 1.1 0.8 549128 6820 ? Ssl 15:45 0:00 /usr/libexec/cockpit-tls system_u:system_r:cockpit_ws_t:s0 cockpit+ 1147 2.6 1.2 311460 10292 ? Ssl 15:45 0:00 /usr/libexec/cockpit-ws --for-tls-proxy --port=0 system_u:system_r:cockpit_session_t:s0 root 1159 0.2 0.8 143592 7212 ? S 15:45 0:00 /usr/libexec/cockpit-session localhost 7. I successfully ran cockpit's TLS and certificate auth tests against that image. So from my POV this works great, and I consider this verified. Thanks Lukas! I just can't formally set "VERIFIED" -- Honza, do you have a way to re-run your sanity tests once this is in the nightly compose, and sign off here? Thanks! I also sent https://github.com/cockpit-project/cockpit/pull/13301 to drop the %post hack.
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:1773