Created attachment 1074408 [details] Extract form journalctl for ssh login as root and command "systemctl status sshd" Description of problem: After upgrading from selinux-policy-targeted-3.13.1-128.12.fc22.noarch to selinux-policy-targeted-3.13.1-128.13.fc22.noarch the system is not manageable anymore: No services can be checked, stoped, started, restarted, because the command systemctl with an unit specified will fail. Example: # systemctl status sshd Failed to get properties: Access denied Only "systemctl" and "systemctl status" (without other arguments) works as usual. And, very important, reboot is not possible. It doesn't work. reboot sends a messages, but nothing other happens, the system is still running after several minutes: # reboot Failed to start reboot.target: Access denied Broadcast message from root.com on pts/1 (Do 2015-09-17 13:46:48 CEST): The system is going down for reboot NOW! (and the system is still running...) Version-Release number of selected component (if applicable): selinux-policy-targeted-3.13.1-128.13.fc22.noarch How reproducible: Always Steps to Reproduce: 1. Upgrade from selinux-policy-targeted-3.13.1-128.12.fc22.noarch to selinux-policy-targeted-3.13.1-128.13.fc22.noarch 2. Enter "systemctl status sshd" 3. Reboot the system using "reboot" Actual results: Error messages as printed above, systemctl commands does not work. System does not reboot. Expected results: No error messages, systemctl commands work. System reboots. Additional info: I append an extract of journalctl for the time when I login as root via ssh and enter the command "systemctl status sshd" (after upgrading to selinux-policy-targeted-3.13.1-128.13.fc22).
Now I have rebooted the system with "reboot -f". This has rebooted the system - but normally this should not be used because of the risk of file corruption. Now, after the reboot, systemctl works as usual, and reboot does it's job again (reboots the system). It seams that after reboot the system works fine again, with selinux-policy-targeted-3.13.1-128.13.fc22 installed. But right after installation of selinux-policy-targeted-3.13.1-128.13.fc22 the system cannot be administrated by systemctl, and clean reboot is not possible (at least not with "reboot" which uses systemctl...).
I've seen this output from journalctl -f -l, when using reboot: Sep 18 19:21:31 localhost.localdomain audit[1]: <audit-1107> pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { start } for auid=0 uid=0 gid=0 path="/usr/lib/systemd/system/reboot.target" cmdline="reboot" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:power_unit_file_t:s0 tclass=service exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?' Sep 18 19:21:31 localhost.localdomain kernel: audit: type=1107 audit(1442596891.817:554): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { start } for auid=0 uid=0 gid=0 path="/usr/lib/systemd/system/reboot.target" cmdline="reboot" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:power_unit_file_t:s0 tclass=service exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?' Thanks for the "reboot -f" workaround.
It is allowed in RHEL. could you do a yum update selinux-policy-targeted Or if that fails yum reinstall selinux-policy-targeted
On Fedora 22, on a "failed" system which I have not rebooted until now: (In reply to Daniel Walsh from comment #3) > yum update selinux-policy-targeted This tells me that nothing is to do. > yum reinstall selinux-policy-targeted This resinstalls selinux-policy-targeted, but the error remains: # systemctl status sshd Failed to get properties: Access denied From journalctl: audit[1]: <audit-1107> pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { status } for auid=0 uid=0 gid=0 path="/usr/lib/systemd/system/sshd.service" cmdline="systemctl status sshd" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sshd_unit_file_t:s0 tclass=service exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
I had the following idea: As reboot fixes the failed systemctl, it may be sufficient to restart systemd. Based on the audit reports it seems that SELinux prevents to do this by systemctl. So the following procedure may solve the problem without rebooting: - Transfer SELinux to permissive mode. # setenforce 0 - Try if systemctl commands works again (just to see if there are a chance that "systemctl daemon-reexec" will work). # systemctl status sshd ● sshd.service - OpenSSH server daemon Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled) Active: active (running) since Mi 2015-09-16 04:53:14 CEST; 4 days ago Docs: man:sshd(8) man:sshd_config(5) Main PID: 12556 (sshd) CGroup: /system.slice/sshd.service ├─11984 sshd: root@pts/0 ├─11988 -bash ├─12242 systemctl status sshd └─12556 /usr/sbin/sshd -D - Restart systemd. # systemctl daemon-reexec - Transfer back to SELinux enforcing mode. # setenforce 1 - Try if systemctl commands still works. # systemctl status sshd ● sshd.service - OpenSSH server daemon Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled) Active: active (running) since Mi 2015-09-16 04:53:14 CEST; 4 days ago Docs: man:sshd(8) man:sshd_config(5) Main PID: 12556 (sshd) CGroup: /system.slice/sshd.service ├─11984 sshd: root@pts/0 ├─11988 -bash ├─12556 /usr/sbin/sshd -D └─13494 systemctl status sshd - I also did check the running systemd processes before and after restarting systemd. I seems that the pid has not changed. (It may be that this is normal.) # ps -ef|grep system root 1 0 0 Sep15 ? 00:00:23 /usr/lib/systemd/systemd --system --deserialize 25 root 1030 1 0 Sep15 ? 00:00:16 /usr/lib/systemd/systemd-journald root 1450 1 0 Sep15 ? 00:00:01 /usr/lib/systemd/systemd-logind dbus 1496 1 0 Sep15 ? 00:00:03 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation root 12321 11988 0 13:18 pts/0 00:00:00 grep --color=auto system root 23798 1 0 Sep17 ? 00:00:00 /usr/lib/systemd/systemd-udevd # systemctl daemon-reexec # ps -ef|grep system root 1 0 0 Sep15 ? 00:00:23 /usr/lib/systemd/systemd --system --deserialize 22 root 1030 1 0 Sep15 ? 00:00:16 /usr/lib/systemd/systemd-journald root 1450 1 0 Sep15 ? 00:00:01 /usr/lib/systemd/systemd-logind dbus 1496 1 0 Sep15 ? 00:00:03 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation root 12354 11988 0 13:18 pts/0 00:00:00 grep --color=auto system root 23798 1 0 Sep17 ? 00:00:00 /usr/lib/systemd/systemd-udevd
After doing the steps in comment #5, the systems reboots with "reboot". No "reboot -f" is neccessary.
Edgar, you are correct. systemctl daemon-reexec is needed to make it working. The problem is with policy update which is not paired with systemd update. There are backported policy changes which require also systemd reload to make SELinux+systemd working correctly.
*** Bug 1264979 has been marked as a duplicate of this bug. ***
There is an upstream patch for libselinux which should help here. We are working on it.
*** Bug 1263913 has been marked as a duplicate of this bug. ***
Ok I am going to fix by adding systemctl daemon-reexec for F22. I don't see another good way how to fix it ASAP in F22. I have been testing and it works fine. Also I have been consulting it with systemd folks. Thanks guys.
selinux-policy-3.13.1-128.16.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-16589
selinux-policy-3.13.1-128.16.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update selinux-policy' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-16589
libselinux-2.4-4.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-a0c7862cfa
libselinux-2.4-4.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update libselinux' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-a0c7862cfa
libselinux-2.4-4.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
selinux-policy-3.13.1-128.16.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.