Bug 1761765

Description of problem: I'm currently trying to lock down the permissions of cockpit.service (in version 205+ we can finally do that in a meaningful way).

But it seems some SELinux policy prevents using systemd's features like PrivateTmp=, ProtectHome=, and similar ones that set up a private mount namespace. Others that don't involve mount name spaces, like NoNewPrivileges=true or MemoryDenyWriteExecute=true do work.


Version-Release number of selected component (if applicable):

selinux-policy-3.14.4-35.fc31.noarch
cockpit-204-1.fc31

How reproducible: Always


Steps to Reproduce:
1. echo PrivateTmp=true >> /usr/lib/systemd/system/cockpit.service
2. systemctl daemon-reload; systemctl stop cockpit; systemctl start cockpit.socket
3. visit http://localhost:9090

Actual results: Browser fails with "The connection was reset", and journal shows errors:

audit[10307]: AVC avc:  denied  { mounton } for  pid=10307 comm="(emotectl)" path="/run/systemd/unit-root/run/cockpit/tls" dev="tmpfs" ino=59323 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:cockpit_var_run_t:s0 tclass=dir permissive=0

cockpit.service: Failed to set up mount namespacing: /run/systemd/unit-root/run/cockpit/tls: Permission denied

Expected results: cockpit.service starts and login works

This looks very similar for ProtectSystem=true and others.



I tried with the full glory:

User=cockpit-ws
Group=cockpit-ws
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
rivateTmp=true
PrivateDevices=true
ProtectKernelTunables=true
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
MemoryDenyWriteExecute=true

This works after `setenforce 0`. This shows another follow-up error which is also relevant:

AVC avc:  denied  { nnp_transition } for  pid=10443 comm="(kpit-tls)" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:cockpit_ws_t:s0 tclass=process2 permissive=1