Hide Forgot
Description of problem: As part of adding smart card authentication support to Cockpit, I'm adding a new /usr/libexec/cockpit-cert-session auth command to Cockpit. This is similar to the existing /usr/libexec/cockpit-session, except that it maps a client-side TLS certificate to a user name via sssd [1] instead of the user/password PAM auth. By and large this needs the same cockpit_session_t privileges as cockpit-session, except that in addition it also needs to be allowed to talk to sssd on D-Bus. So for the new binary I did semanage fcontext -a /usr/libexec/cockpit-cert-session -t cockpit_session_exec_t restorecon /usr/libexec/cockpit-cert-session and to allow D-Bus with sssd I did cat <<EOF > /tmp/local.te module local 1.0; require { type cockpit_session_t; type sssd_t; class dbus send_msg; } allow cockpit_session_t sssd_t:dbus send_msg; allow sssd_t cockpit_session_t:dbus send_msg; EOF checkmodule -M -m -o /tmp/local.mod /tmp/local.te semodule_package -o /tmp/local.pp -m /tmp/local.mod semodule -i /tmp/local.pp With these, everything works fine in enforcing mode, without any (new) avc denials. [1] https://www.freeipa.org/page/V4/User_Certificates Version-Release number of selected component (if applicable): selinux-policy-3.14.2-51.fc29.src.rpm
PR created: https://github.com/fedora-selinux/selinux-policy-contrib/pull/92
Martin, When is this feature expected to be added - is F30 as the target release enough?
@Zdenek, Yes, absolutely. We'll also need it in RHEL downstream at some point, but I'll clone this bug/file it once it becomes relevant. I'm filing this early to avoid a rush on any side. Is the information enough here, or should I try and translate the /tmp/local.te into a PR for selinux-policy? Thanks!
Martin, I created the PR based on your request stating it is enough for the feature to be working, just using existing interface. Feel free to review or try out.
Hang on, on Fedora 29 (not on RHEL 8 or anywhere else) I get these two violations. They don't break the operation, but still cause unexpected log errors: audit: type=1400 audit(1553006049.704:621): avc: denied { map } for pid=8208 comm="pool" path="/etc/pki/ca-trust/source/README" dev="dm-0" ino=8538086 scontext=system_u:system_r:cockpit_ws_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=file permissive=0 audit: type=1400 audit(1553006049.710:622): avc: denied { map } for pid=8208 comm="pool" path="/etc/pki/ca-trust/source/ipa.p11-kit" dev="dm-0" ino=9401424 scontext=system_u:system_r:cockpit_ws_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=file permissive=0 I'm not sure what "pool" is (there is no such binary), but I'm fairly sure that this is cockpit's web server trying to validate the TLS certificate, through glib-networking → gnutls. I'll play around with that a bit and see how to extend the policy to allow this. At this point I suppose it's better to follow up on the PR. Thank you!
Base policy PR for miscfiles_dontaudit_map_generic_certs interface: https://github.com/fedora-selinux/selinux-policy/pull/252
selinux-policy-3.14.2-53.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-bf377d92c7
selinux-policy-3.14.2-53.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-bf377d92c7
selinux-policy-3.14.2-53.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
For the record, these changes are *not* present in F29, and also not mentioned in the selinux-policy-3.14.2-53.fc29 changelog. I assume the bug should have been closed in F30 only?