Bug 1264051 - selinux-policy-targeted-3.13.1-128.13.fc22 breaks systemctl, and prevents reboot
selinux-policy-targeted-3.13.1-128.13.fc22 breaks systemctl, and prevents reboot
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
22
Unspecified Linux
urgent Severity urgent
: ---
: ---
Assigned To: Miroslav Grepl
Ben Levenson
:
: 1263913 1264979 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-17 08:01 EDT by Edgar Hoch
Modified: 2015-10-03 17:14 EDT (History)
8 users (show)

See Also:
Fixed In Version: selinux-policy-3.13.1-128.15.fc22
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-10-03 13:32:41 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Extract form journalctl for ssh login as root and command "systemctl status sshd" (9.40 KB, text/plain)
2015-09-17 08:01 EDT, Edgar Hoch
no flags Details

  None (edit)
Description Edgar Hoch 2015-09-17 08:01:37 EDT
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@myhost.example.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).
Comment 1 Edgar Hoch 2015-09-17 11:08:55 EDT
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...).
Comment 2 Stephan Dühr 2015-09-18 13:37:27 EDT
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.
Comment 3 Daniel Walsh 2015-09-18 13:42:01 EDT
It is allowed in RHEL.

could you do a 
yum update selinux-policy-targeted

Or if that fails

yum reinstall selinux-policy-targeted
Comment 4 Edgar Hoch 2015-09-18 13:54:38 EDT
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=?'
Comment 5 Edgar Hoch 2015-09-20 10:58:42 EDT
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
Comment 6 Edgar Hoch 2015-09-20 11:12:53 EDT
After doing the steps in comment #5, the systems reboots with "reboot".
No "reboot -f" is neccessary.
Comment 7 Miroslav Grepl 2015-09-21 03:23:01 EDT
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.
Comment 8 Jan Synacek 2015-09-22 05:55:26 EDT
*** Bug 1264979 has been marked as a duplicate of this bug. ***
Comment 9 Miroslav Grepl 2015-09-23 06:39:44 EDT
There is an upstream patch for libselinux which should help here. We are working on it.
Comment 10 Jan Synacek 2015-09-24 03:05:06 EDT
*** Bug 1263913 has been marked as a duplicate of this bug. ***
Comment 11 Miroslav Grepl 2015-09-24 06:01:59 EDT
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.
Comment 12 Fedora Update System 2015-09-24 08:18:42 EDT
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
Comment 13 Fedora Update System 2015-09-26 20:39:03 EDT
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
Comment 14 Fedora Update System 2015-09-30 11:31:26 EDT
libselinux-2.4-4.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-a0c7862cfa
Comment 15 Fedora Update System 2015-10-01 19:53:28 EDT
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
Comment 16 Fedora Update System 2015-10-01 21:49:19 EDT
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
Comment 17 Fedora Update System 2015-10-03 13:32:38 EDT
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.
Comment 18 Fedora Update System 2015-10-03 17:14:07 EDT
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.

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