Description of problem: After upgrading to systemd220, the systemd selinux object manager looks broken. Version-Release number of selected component (if applicable): 220 How reproducible: update to v220 and try to do a systemctl restart $SERVICE (or anything requiring an access check) Actual results: Failed to restart $SERVICE.service: Access denied https://github.com/systemd/systemd/commit/8a188de9e0ea41509beda12084126d7a75ebe86eal info: may or may not be related.
actually this commit looks like a more obvious candidate: https://github.com/systemd/systemd/commit/0f51442056157cfec2efc52ddbff7392b0ff674a
also: logind is not removing /run/nologin after a shutdown is cancelled version: 220 step to repr: shutdown -r +1 ls /run/nologin shutdown -c ls /run/nologin
o hum, this is probably related instead: http://cgit.freedesktop.org/systemd/systemd/commit/?id=b860a90ea5afd2da57225195c1cb7edd64a8b73d
*** Bug 1224349 has been marked as a duplicate of this bug. ***
Any fix forthcoming? If you provide me with a link to a scratch built that has b860a90 reverted, then I can try that see if that fixes this issue.
(In reply to dac.override from comment #2) > also: > > logind is not removing /run/nologin after a shutdown is cancelled > > version: 220 > > step to repr: > > shutdown -r +1 > ls /run/nologin > shutdown -c > ls /run/nologin Please file a separate issue about this unrelated bug
Do you see any AVCs in the (audit) logs when this happens? Do you have enforcing mode enabled?
(In reply to dac.override from comment #2) > also: > > logind is not removing /run/nologin after a shutdown is cancelled > > version: 220 > > step to repr: > > shutdown -r +1 > ls /run/nologin > shutdown -c > ls /run/nologin Thanks, this is one now fixed upstream!
Yes there are AVC denials but this is not an selinux policy issue. I tried both permissive mode and enforcing mode. The nature of the AVC denials indicate to me that this is caused by a bug in the SELinux code in systemd itself. Example: May 23 08:15:29 fedoratest1 audit[1]: USER_AVC pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:systemd_t msg='avc: denied { disable } for auid=1000 uid=0 gid=0 path="/usr/lib/systemd/system/pcscd.socket" cmdline="systemctl --no-reload disable pcscd.socket pcscd.service" scontext=system_u:system_r:invalid_t tcontext=system_u:object_r:pcscd_unit_t tclass=service The invalid_t type in the scontext signals that something is invalid. I suspect it may be refering to the access vector here. To figure out what caused this, it may help if we just revert all the selinux code related commits from systemd and then try them one by one to see where it went wrong
(In reply to Lennart Poettering from comment #7) > Do you see any AVCs in the (audit) logs when this happens? > > Do you have enforcing mode enabled? Are you saying that you are not seeing this with systemd 220 in fedora rawhide?
(In reply to Daniel Mack from comment #8) > (In reply to dac.override from comment #2) > > also: > > > > logind is not removing /run/nologin after a shutdown is cancelled > > > > version: 220 > > > > step to repr: > > > > shutdown -r +1 > > ls /run/nologin > > shutdown -c > > ls /run/nologin > > Thanks, this is one now fixed upstream! Thank you
I'm able to reproduce these systemd/selinux issues on my Fedora rawhide installation after upgrading to systemd 220.
(In reply to dac.override from comment #9) <snip> > > To figure out what caused this, it may help if we just revert all the > selinux code related commits from systemd and then try them one by one to > see where it went wrong Since last know good i mean (219) there are not many selinux code related commits since then so it should not be too hard to find where this went wrong.
It has been more or less one week So ... systemd-220-2.fc23 is built but none of the issues above are addressed in that release. What i do not understand is: On FOSSDEM you state that "No one understands SELinux except Dan Walsh" (we know what you really were saying was: "I dont understand SELinux, and i dont want it"), But then why mess with the SELinux code that same day as the release??? You sure seem to not have tested it ...
Yes I am seeing something similar allow unlabeled_t docker_unit_file_t:service { status start stop }; allow unlabeled_t init_t:system reload; allow unlabeled_t iscsi_unit_file_t:service { status start reload }; THese indicate that the systemd patch is asking the kernel if a process label has the abiltiy to start/stop these services. unlabeled_t means that the systemd asked with an invalid process label. I beleave the code is looking at the label of the remote process that is attempting to start the service. The label it gets back should look like unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 In most cases. If this label is corrupted you could see AVC's like this.
Yes, the label is not set correctly. I should have a patch ready today.
Hm, this is confusing. This "bad" label comes from SCM_SECURITY control data for the incoming connection on /run/systemd/private. It is stored as bus->label, and then copied over to the message. In the same control structure, there are SCM_CREDENTIALS which point to the right process (pid, uid, gid all match). But the SCM_SECURITY label is not the label of the process. It should be unconfined_u:unconfined_r:unconfined_t:s0, but is system_u:object_r:unlabeled_t:s0. So it seems that SCM_SECURITY is something different then the label of the process that we're communicating with. Unfortunately SCM_SECURITY is mostly undocumented, so I don't know if this is some gross misunderstanding or a bug.
Can you plesse build a package with those commits reverted and withthe logind fixes for now? Then first study that SCM_SECURITY functionality first before you implement it please?
Eric and Paul, do you have any idea?
We haven't changed anything with respect to SCM_SECURITY is a long time. Is the socket still a AF_UNIX socket or has it changed to something else?
It's still a unix socket (/run/systemd/private).
Based on what I've read here, I tend to agree with the reporter that this looks like a regression in systemd and not necessarily an issue with the kernel. Since there is a "known good" and a "known bad" version of systemd, I would suggest bisecting systemd to identify the problematic commit. Once we see the offending code, we can better comment on the cause of the problem.
I did a bit of investigation on this one and found out that with older build systemd-219-15.fc23.x86_64 we never populate bus label in bus_socket_read_auth() and value remains set to empty string. This is not the case with systemd-220-3.fc23.x86_64, where bogus label is copied from cmsg to b->label. However, according to comment in commit [1] above shouldn't really matter though, strange. [1] https://github.com/systemd-devs/systemd/commit/038f9863e22295d0e22b3b79a6d54f7086525ba2
The label was filled in some other way: Before 0f51442056157cfec2efc52ddbff7392b0ff674a: May 27 16:25:34 f22-uefi kernel: audit: type=1105 audit(1432758334.279:514): pid=21858 uid=0 auid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' Then: commit 0f51442056157cfec2efc52ddbff7392b0ff674a Author: Lennart Poettering <lennart> Date: Tue Apr 21 00:58:08 2015 +0200 sd-bus: when augmenting creds, remember which ones were augmented Also, when we do permissions checks using creds, verify that we don't do so based on augmented creds, as extra safety check. May 27 16:14:27 f22-uefi systemd[1]: Assertion '(sd_bus_creds_get_augmented_mask(creds) & SD_BUS_CREDS_SELINUX_CONTEXT) == 0' failed at src/core/selinux-access.c:231, function mac_selinux_generic_access_check(). Ignoring. Then: commit 0674bbea9ce0958512411962c2d1623d88dad0b4 Author: Lennart Poettering <lennart> Date: Thu Apr 23 00:37:47 2015 +0200 core: explicitly specify credentials for direct connections, too So far we authenticate direct connections primarily at connection time, but let's also do this for each method individually, by attaching the creds we need for that right away. May 27 16:26:38 f22-uefi audit[1]: USER_AVC pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { status } for auid=1000 uid=0 gid=0 cmdline="systemctl list-units" scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=system exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?' (gdb) p b->label $1 = "system_u:object_r:unlabeled_t:s0", '\000' <repeats 222 times> (gdb) bt #0 bus_socket_read_auth (b=0x55e71fde34f0) at src/libsystemd/sd-bus/bus-socket.c:557 #1 0x000055e71e7dc8f8 in bus_socket_process_authenticating (b=0x55e71fde34f0) at src/libsystemd/sd-bus/bus-socket.c:1096 #2 0x000055e71e79270c in bus_process_internal (bus=0x55e71fde34f0, hint_priority=false, priority=0, ret=0x0) at src/libsystemd/sd-bus/sd-bus.c:2735 #3 0x000055e71e79284d in sd_bus_process (bus=0x55e71fde34f0, ret=0x0) at src/libsystemd/sd-bus/sd-bus.c:2768 #4 0x000055e71e7931ac in io_callback (s=0x55e71fde3380, fd=14, revents=1, userdata=0x55e71fde34f0) at src/libsystemd/sd-bus/sd-bus.c:3027 #5 0x000055e71e7997f1 in source_dispatch (s=0x55e71fde3380) at src/libsystemd/sd-event/sd-event.c:2114 #6 0x000055e71e79ab82 in sd_event_dispatch (e=0x55e71fd64220) at src/libsystemd/sd-event/sd-event.c:2471 #7 0x000055e71e79acfa in sd_event_run (e=0x55e71fd64220, timeout=18446744073709551615) at src/libsystemd/sd-event/sd-event.c:2499 #8 0x000055e71e6bae21 in manager_loop (m=0x55e71fd63b00) at src/core/manager.c:2050 #9 0x000055e71e6b2b3f in main (argc=5, argv=0x7ffc1dddd0f8) at src/core/main.c:1754
OK, so before http://cgit.freedesktop.org/systemd/systemd/commit/?id=0f51442056, SO_PASSSEC is not set for connections over /run/systemd/private UNIX socket, so bus_socket_read_auth() does not set the label, and the label is filled in in a "racy" way in bus_creds_extend_by_pid→bus_creds_add_more. We read /proc/<pid>/attr/current and set the label to unconfined_u:unconfined_r:unconfined_t systemd[1]: SELinux access check scon=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcon=system_u:system_r:init_t:s0 tclass=system perm=status path=(null) cmdline=systemctl list-unit-files: 0 After http://cgit.freedesktop.org/systemd/systemd/commit/?id=0f51442056 things are broken because we refuse to use "racy" information, but SO_PASSSEC is not set, so we fail with an assertion: systemd[1]: Assertion '(sd_bus_creds_get_augmented_mask(creds) & SD_BUS_CREDS_SELINUX_CONTEXT) == 0' failed at src/core/selinux-access.c:231, function mac_selinux_generic_access_check(). Ignoring. After http://cgit.freedesktop.org/systemd/systemd/commit/?id=0674bbea9c, SD_BUS_CREDS_SELINUX_CONTEXT is set, so KDBUS_ATTACH_SECLABEL is set, so SO_PASSSEC is set, and we get SCM_SECURITY metadata, which turns out to be system_u:object_r:unlabeled_t:s0. Now this part is confusing. Based on the patch adding SO_PASSSEC: This patch enables a security-aware application to retrieve the security context of the peer of a Unix datagram socket. The application can then use this security context to determine the security context for processing on behalf of the peer who sent the packet. When I run systemctl --user list-unit-files, the following "actors" are involved: system_u:system_r:init_t:s0 15349 ? ts 0:00 /usr/lib/systemd/systemd --user unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 15378 pts/1 T 0:00 systemctl --user list-unit-files system_u:object_r:user_tmp_t:s0 /run/user/1000/systemd/private and the label from SCM_SECURITY ends up "system_u:object_r:unlabeled_t:s0". A question: is it context coming from the socket file in the fs (apart from unlabeled_t)? Then it would more or less useless for security decisions...
Help please! I think #c25 contains the info needed, but someone with a better understanding of how labels work should look at this.
You are supposed to be getting the label of the process that is
You are supposed to be getting the label of the process that is connecting to the socket. This should be getpeercon in SELInux terms.
But I'm not! The process on the other end is unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023, and I get system_u:object_r:unlabeled_t:s0. The information from SCM_CREDENTIALS matches that process (pid, uid, gid), but the information from SCM_SECURITY does not.
In the kernel, include/net/scm.h:scm_send() calls unix_get_peersec_dgram(), which calls security_socket_getpeersec_dgram(), which calls selinux_socket_getpeersec_dgram(), which calls selinux_inode_getsecid, which copies out the socket inode SID. This is ultimately set in scm->secid. This should be the sender SID unless the sender used setsockcreatecon() to assign a specific context to the socket other than its own. Then in scm_passsec(), if SOCK_PASSSEC is set in the socket flags, we call security_secid_to_secctx() on the scm->secid, and put the resulting data and length into the cmsg as SCM_SECURITY data. So you should be getting the sender security context. If not, that's a kernel bug. Not sure who else if anyone is using this facility though; most programs are only using getpeercon with stream sockets.
Created attachment 1035340 [details] trivial server program to demonstrate SCM_SECURITY
Created attachment 1035341 [details] trivial client program to demonstrate SCM_SECURITY
$ gcc -o server server.c $ gcc -o client client.c $ ./server & $ ./client sent 100 bytes Got message from unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 $uname -r 4.0.4-202.fc21.x86_64
Oh, I see - you are using this with stream sockets. Never supported by the kernel. SCM_SECURITY was only added for datagram sockets. For stream sockets, use getpeercon() aka SO_PEERSEC.
BTW, checking credentials on each message rather than the original connection can be dangerous, e.g. process sets up descriptors 0-2 to refer to a socket it created and connected to a server, then invokes setuid program in a manner to cause it to write predictable output to that socket.
*** Bug 1225488 has been marked as a duplicate of this bug. ***
I created a pull request upstream on https://github.com/systemd/systemd/pull/85. Patches 2/3 and 3/4 form the gist. Reviews would be welcome... This touches some core security logic in systemd.
Independent of this bug, we should likely get SCM_SECURITY properly added to the linux/include/uapi or at least glibc headers and documented in the relevant man pages. Also might want to look at how/why it doesn't work for stream sockets and whether we can either change the kernel either to support that or to more cleanly indicate an error there.
*** Bug 1229416 has been marked as a duplicate of this bug. ***
See my comment here: https://github.com/keszybz/systemd/commit/e3d37952af687f435b187cffc7d443e8f5be759e#commitcomment-11572848 paste: "Humm, no. The dbus spec specifically says an initial 0 byte should be sent that has the user creds attached via SCM_CREDS, and that that should be used for authentication. I am pretty sure we should not deviate unnecessarily from that: http://dbus.freedesktop.org/doc/dbus-specification.html#auth-nul-byte Moreover, I am pretty sure that if we use the SCM_CREDS info from that NUL byte we should also use the SCM_SECURITY data from it. It appears that the kernel is quite broken if it sends rubbish SCM_SECURITY for stream sockets. Either it should send valid SCM_SECURITY data, or it should not send any SCM_SECURITY data at all, but certainly no rubbish data. And if it does, that's something to fix in the kernel, and not in systemd."
Also, see: https://github.com/systemd/systemd/pull/85#issuecomment-110098645
(In reply to Lennart Poettering from comment #40) > The dbus spec specifically says an initial 0 byte should be sent that has > the user creds attached via SCM_CREDS, and that that should be used for > authentication. I am pretty sure we should not deviate unnecessarily from > that: > > http://dbus.freedesktop.org/doc/dbus-specification.html#auth-nul-byte > > Moreover, I am pretty sure that if we use the SCM_CREDS info from that NUL > byte we should also use the SCM_SECURITY data from it. Even though this is subject to "create a socket, connect to server, dup2 to stderr, and exec a setuid-root and/or label-changing program that writes caller-controlled/influenced output to stderr, delivered to server with SCM_SECURITY with root and/or other label credentials"? > It appears that the kernel is quite broken if it sends rubbish SCM_SECURITY > for stream sockets. Either it should send valid SCM_SECURITY data, or it > should not send any SCM_SECURITY data at all, but certainly no rubbish data. > And if it does, that's something to fix in the kernel, and not in systemd." I agree that we ought to fix the kernel one way or the other. However, SCM_SECURITY has NEVER been supported on stream sockets, nor is SCM_SECURITY even defined by the kernel include/uapi headers or glibc headers, nor is there any evident man page or other documentation for it that I can see (and it was never exposed or used by libselinux and thus never used by any SELinux-aware application to my knowledge), so you can't rely on this for systemd for any existing kernel. SCM_SECURITY was added by IBM originally for UDP sockets when using labeled IPSEC to convey security contexts, and they only added the Unix datagram socket support as an afterthought IIRC. In contrast, SO_PEERSEC was first implemented for Unix stream sockets (long before SCM_SECURITY), and then later implemented for TCP sockets when using labeled IPSEC or NetLabel to convey the contexts, and wrapped by libselinux and used by applications.
For what it's worth, libdbus uses SO_PEERCRED and SO_PEERSEC, not SCM_CREDENTIALS and SCM_SECURITY. As far as I'm aware, Linux doesn't have SCM_CREDS (that's a FreeBSD thing), although Linux SCM_CREDENTIALS is very similar to FreeBSD SCM_CREDS. Is that true? In any case, if Linux did have SCM_CREDS, libdbus as currently implemented would still prefer SO_PEERCRED.
*** Bug 1229573 has been marked as a duplicate of this bug. ***
*** Bug 1230035 has been marked as a duplicate of this bug. ***
I have submitted two patches for the kernel: 1. The first one is purely a SELinux-internal change so that we do not end up putting a SCM_SECURITY control message when we do not have any value provided, as in the Unix stream socket case. Previously, this was being transparently remapped to the unlabeled context due to some default logic used to ensure that we provide sane handling for objects whose contexts have become invalid due to a policy reload that rendered their label undefined. So after that change, there won't be a SCM_SECURITY control message at all for Unix stream sockets. 2. The second one is a net/unix change to properly set and propagate the security information for Unix stream sockets so that it is available. After that change, there will be a SCM_SECURITY control message with the correct sender security context information for Unix stream sockets. I am fairly confident the first one will be taken. I am not sure if the second one will - that's up to the networking maintainers. Regardless, given that SCM_SECURITY is not currently supported for stream sockets (and never was previously, so that is not a kernel regression), and given that libdbus uses SO_PEERCRED and SO_PEERSEC, I would think that the correct fix for this bug at this time would be to switch to using SO_PEERCRED and SO_PEERSEC. If my second patch is taken, then at some future point you could look to switch over to using SCM_CREDENTIALS and SCM_SECURITY if desired, although I do not see the advantage of that over using SO_PEERCRED/PEERSEC for stream sockets.
http://cgit.freedesktop.org/systemd/systemd/commit/?id=b078b5a7ab
FWIW, the second kernel patch was accepted into net-next, so probably will be in Linux 4.2. So SCM_SECURITY will be fully supported on Unix stream sockets in future kernels. Probably doesn't matter for this bug, but just to close the loop.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #47) > http://cgit.freedesktop.org/systemd/systemd/commit/?id=b078b5a7ab systemd-220-8.fc23.x86_64 fixes the issue on my test vm.
Thank. systemd-220-8.fc23 solve for me bug: 1229573
(In reply to Stephen Smalley from comment #46) > I have submitted two patches for the kernel: > 1. The first one is purely a SELinux-internal change so that we do not end > up putting a SCM_SECURITY control message when we do not have any value > provided, as in the Unix stream socket case. Previously, this was being > transparently remapped to the unlabeled context due to some default logic > used to ensure that we provide sane handling for objects whose contexts have > become invalid due to a policy reload that rendered their label undefined. > So after that change, there won't be a SCM_SECURITY control message at all > for Unix stream sockets. As an update, I've queued this up in the SELinux tree for after the v4.2 merge window.
I just installed Fedora 22 and I'm not able to reboot. After attempting to restart from the within the GUI failed repeatedly, I opened a terminal, did an su -, and then "shutdown -r now" but it fails with the message "Failed to start reboot.target: Access denied" I searched and found bug 1229416 which sounds like it describes my bug but it was closed as a dupe of this bug which doesn't sound like my problem or have any helpful info (that I can decipher at least). Can anyone tell me how to safely shutdown and reboot Fedora 22? Thanks!
Update: found a forum post somewhere with the answer. Seems you have to hit Ctrl-Alt-Del repeatedly and eventually you get a shutdown and reboot. Took about 10 successive Ctrl-Alt-Dels for me before the shutdown initiated. The other people on the forum reported varying numbers of tries so it seems random. Hope that helps locating the bug. Once I got the work around for rebooting, I was able to do a yum update (sorry, dnf update - why do you have to randomly rename common utilities and to worse names at that, grrrrrr) and after the update and another reboot, things seem to be working normally now.
Seems like this bug made it into Fedora 22 with systemd-219-24.fc22.x86_64 -- impossible to shutdown the system.
Do you have any output from ausearch -m AVC,USER_AVC,SELINUX_ERR -ts recent?
time->Fri Sep 18 19:51:35 2015 type=USER_AVC msg=audit(1442598695.558:1254): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { status } for auid=1000 uid=0 gid=0 path="/usr/lib/systemd/system/firewalld.service" cmdline="systemctl status firewalld.service" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:firewalld_unit_file_t:s0 tclass=service exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?' ---- time->Fri Sep 18 19:51:36 2015 type=USER_AVC msg=audit(1442598696.559:1255): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { status } for auid=1000 uid=0 gid=0 path="/usr/lib/systemd/system/firewalld.service" cmdline="systemctl status firewalld.service" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:firewalld_unit_file_t:s0 tclass=service exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?' ---- time->Fri Sep 18 19:51:37 2015 type=USER_AVC msg=audit(1442598697.391:1256): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { status } for auid=1000 uid=0 gid=0 path="/usr/lib/systemd/system/firewalld.service" cmdline="systemctl status firewalld.service" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:firewalld_unit_file_t:s0 tclass=service exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
That doesn't look the same as this bug (the scontext= value is correct above, unlike in comment 9). Does your policy allow the permission being denied in your output? $ sudo yum install setools-console $ sesearch -A -s unconfined_t -t firewalld_unit_file_t -c service -p status Found 3 semantic av rules: allow unconfined_t systemd_unit_file_type : service { start stop status reload enable disable } ; allow unconfined_domain_type file_type : service { start stop status reload enable disable } ; allow files_unconfined_type file_type : service { start stop status reload enable disable } ; If policy does not allow it, then the bug is in the policy. If the policy does allow it, then that suggests either a bug in systemd or a mismatch between systemd's definitions of the permissions and the policy definitions. Did the problem only occur upon a systemd update or was it an update that included systemd and selinux-policy-targeted?
going through my dnf history just selinux-policy-targeted ... I have the same 3 av rules you list. So policy seems correct. How can i verify this is systemd instead?
Wait, you said that only updated selinux-policy-targeted, not systemd? What versions of each?
I could be wrong, but this looks to me like a policy bug. Please file against selinux-policy-targeted. They changed the security_class definitions in an unsafe manner, which will break running programs that assume that the values don't change underneath them on the fly. Rebooting the system (i.e. restarting systemd) should fix it.
systemd 219-24.fc22 selinux-policy-targeted 3.13.1-128.13.fc22 and yes just selinux updated since the last reboot. Indeed rebooting the system fixed the problem! Thanks!
Reproducer: Downgrade to selinux-policy* 3.13.1-122.fc22 Run a little program that keeps retrying selinux_check_access() with the above values until it encounters a denial (will attach). Upgrade to selinux-policy 3.13.1-128.13.fc22. Program will fail when it tries again. Service class value changed underneath it.
Created attachment 1075041 [details] Trivial program to demonstrate failure after policy update
In my case, when I did the first "dnf update" it installed over 700MB of updates, so kind of hard to know exactly what fixed it. Both systemd and selinux were updated.
This seems to happen if the selinux update happens to be done _after_ the systemd update (if they are in the same transaction). If the selinux update is applied first everything is fine. You can workaround by also doing systemctl daemon-reexec
Yes, a new one is selinux-policy issue where rawhide changes have been backported to F22 which causes problems how Stephen wrote above. See https://bugzilla.redhat.com/show_bug.cgi?id=1264051
Could you add a trigger to systemctl daemon-rexec on older selinux-policy?
(In reply to Daniel Walsh from comment #67) > Could you add a trigger to systemctl daemon-rexec on older selinux-policy? We definitely need to find out a way how to deliver a solution and probably also for a future.
I think we should do that ordinarily in %post. Does it make sense for you guys?
The real fix would be to have systemd realize it happened and reload its own policy.
The class/perm mappings are cached by libselinux; systemd doesn't even know about them.
I thought libselinux/systemd can realize when the policy has been updated and dump its cache?
That's the AVC in libselinux. Yes, that already gets flushed. But the dynamic class/perm string mappings weren't being flushed (see my patch on selinux list).
The bug propagated to Fedora 22 after today update. Should a new bug be opened for that?
I found a workaround for the most recent problem in F22: dnf -y distro-sync # this might create a systemd SELinux problem if ! (systemctl list-sockets >/dev/null && systemctl list-dependencies >/dev/null) then dnf -y reinstall systemd if systemctl list-sockets >/dev/null && systemctl list-dependencies >/dev/null then echo "Update-related systemd SELinux problem: FIXED" else echo "sorry, systemd still has SELinux trouble" fi fi i.e. just performing 'dnf -y reinstall systemd' solved it for me
And yes, systemctl daemon-reexec also works and is even faster ...
(In reply to Thorsten Kohfeldt from comment #76) > And yes, > > systemctl daemon-reexec > > also works and is even faster ... We have F22 policy update to address this issue.
Will that policy UPDATE help in case of a dnf distro-sync performed on an 'early' F22 cloud image (non-atomic) ? I have the impression that it is maybe more important, where an update "starts upon" than where it is intended "to end at".
*** Bug 1263570 has been marked as a duplicate of this bug. ***
Thorsten: it should, because the change made was to run systemctl daemon-reexec in selinux-policy %post.
We have libselinux fixes to prevent this issue in the future but we still need to run systemctl daemon-reexec to solve the current troubles.