Bug 1771414 - Update Cockpit SELinux policy for cockpit-tls and client certificate authentication [NEEDINFO]
Summary: Update Cockpit SELinux policy for cockpit-tls and client certificate authenti...
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: selinux-policy
Version: 8.2
Hardware: All
OS: Linux
Target Milestone: rc
: 8.2
Assignee: Zdenek Pytela
QA Contact: Milos Malik
Depends On:
Blocks: 1678465
TreeView+ depends on / blocked
Reported: 2019-11-12 10:15 UTC by Martin Pitt
Modified: 2020-04-28 16:42 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-04-28 16:41:41 UTC
Type: Feature Request
Target Upstream Version:
jscotka: needinfo? (mmalik)

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:1773 0 None None None 2020-04-28 16:42:15 UTC

Description Martin Pitt 2019-11-12 10:15:42 UTC
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:


If you rather want to cherry-pick than sync, we need these commits:


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.

Comment 8 Martin Pitt 2019-12-16 20:56:25 UTC

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.

Comment 11 errata-xmlrpc 2020-04-28 16:41:41 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.


Note You need to log in before you can comment on or make changes to this bug.