Bug 1224211 - systemd selinux code seems to be broken in v220
Summary: systemd selinux code seems to be broken in v220
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: rawhide
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: ---
Assignee: Zbigniew Jędrzejewski-Szmek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1224349 1225488 1229416 1229573 1230035 1263570 (view as bug list)
Depends On:
Blocks: F23FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2015-05-22 10:38 UTC by dac.override
Modified: 2017-01-04 09:53 UTC (History)
35 users (show)

Fixed In Version: systemd-220-8.fc23.x86_64
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1340765 1410034 (view as bug list)
Environment:
Last Closed: 2015-06-11 13:54:09 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
trivial server program to demonstrate SCM_SECURITY (1.73 KB, text/plain)
2015-06-05 14:33 UTC, Stephen Smalley
no flags Details
trivial client program to demonstrate SCM_SECURITY (909 bytes, text/plain)
2015-06-05 14:34 UTC, Stephen Smalley
no flags Details
Trivial program to demonstrate failure after policy update (440 bytes, text/x-csrc)
2015-09-18 19:43 UTC, Stephen Smalley
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1273427 0 unspecified CLOSED anaconda won't reboot the system 2021-02-22 00:41:40 UTC

Internal Links: 1273427

Description dac.override 2015-05-22 10:38:21 UTC
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.

Comment 1 dac.override 2015-05-22 12:38:07 UTC
actually this commit looks like a more obvious candidate:

https://github.com/systemd/systemd/commit/0f51442056157cfec2efc52ddbff7392b0ff674a

Comment 2 dac.override 2015-05-22 12:45:43 UTC
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

Comment 3 dac.override 2015-05-22 15:44:16 UTC
o hum, this is probably related instead: http://cgit.freedesktop.org/systemd/systemd/commit/?id=b860a90ea5afd2da57225195c1cb7edd64a8b73d

Comment 4 Kevin Fenzi 2015-05-22 16:34:51 UTC
*** Bug 1224349 has been marked as a duplicate of this bug. ***

Comment 5 dac.override 2015-05-26 15:00:28 UTC
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.

Comment 6 Lennart Poettering 2015-05-26 16:40:39 UTC
(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

Comment 7 Lennart Poettering 2015-05-26 16:42:20 UTC
Do you see any AVCs in the (audit) logs when this happens?

Do you have enforcing mode enabled?

Comment 8 Daniel Mack 2015-05-26 17:00:25 UTC
(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!

Comment 9 dac.override 2015-05-26 19:07:06 UTC
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

Comment 10 dac.override 2015-05-26 19:13:16 UTC
(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?

Comment 11 dac.override 2015-05-26 19:13:40 UTC
(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

Comment 12 Morten Stevens 2015-05-26 19:21:51 UTC
I'm able to reproduce these systemd/selinux issues on my Fedora rawhide installation after upgrading to systemd 220.

Comment 13 dac.override 2015-05-26 19:43:27 UTC
(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.

Comment 14 dac.override 2015-05-27 15:47:01 UTC
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 ...

Comment 15 Daniel Walsh 2015-05-28 20:21:15 UTC
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.

Comment 16 Zbigniew Jędrzejewski-Szmek 2015-05-28 20:23:02 UTC
Yes, the label is not set correctly. I should have a patch ready today.

Comment 17 Zbigniew Jędrzejewski-Szmek 2015-05-29 06:04:13 UTC
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.

Comment 18 dac.override 2015-05-29 06:09:08 UTC
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?

Comment 19 Daniel Walsh 2015-06-01 12:56:30 UTC
Eric and Paul, do you have any idea?

Comment 20 Paul Moore 2015-06-01 13:23:13 UTC
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?

Comment 21 Zbigniew Jędrzejewski-Szmek 2015-06-01 14:06:53 UTC
It's still a unix socket (/run/systemd/private).

Comment 22 Paul Moore 2015-06-01 21:33:19 UTC
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.

Comment 23 Michal Sekletar 2015-06-02 12:27:22 UTC
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

Comment 24 Zbigniew Jędrzejewski-Szmek 2015-06-02 13:11:15 UTC
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

Comment 25 Zbigniew Jędrzejewski-Szmek 2015-06-02 21:26:33 UTC
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...

Comment 26 Zbigniew Jędrzejewski-Szmek 2015-06-04 13:49:04 UTC
Help please! I think #c25 contains the info needed, but someone with a better understanding of how labels work should look at this.

Comment 27 Daniel Walsh 2015-06-05 13:25:48 UTC
You are supposed to be getting the label of the process that is

Comment 28 Daniel Walsh 2015-06-05 13:29:02 UTC
You are supposed to be getting the label of the process that is connecting to the socket.  This should be getpeercon in SELInux terms.

Comment 29 Zbigniew Jędrzejewski-Szmek 2015-06-05 13:34:32 UTC
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.

Comment 30 Stephen Smalley 2015-06-05 13:46:35 UTC
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.

Comment 31 Stephen Smalley 2015-06-05 14:33:57 UTC
Created attachment 1035340 [details]
trivial server program to demonstrate SCM_SECURITY

Comment 32 Stephen Smalley 2015-06-05 14:34:29 UTC
Created attachment 1035341 [details]
trivial client program to demonstrate SCM_SECURITY

Comment 33 Stephen Smalley 2015-06-05 14:36:01 UTC
$ 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

Comment 34 Stephen Smalley 2015-06-05 15:02:01 UTC
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.

Comment 35 Stephen Smalley 2015-06-05 15:05:01 UTC
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.

Comment 36 Michal Schmidt 2015-06-05 18:37:43 UTC
*** Bug 1225488 has been marked as a duplicate of this bug. ***

Comment 37 Zbigniew Jędrzejewski-Szmek 2015-06-07 01:48:47 UTC
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.

Comment 38 Stephen Smalley 2015-06-08 13:20:46 UTC
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.

Comment 39 Zbigniew Jędrzejewski-Szmek 2015-06-08 16:36:41 UTC
*** Bug 1229416 has been marked as a duplicate of this bug. ***

Comment 40 Lennart Poettering 2015-06-08 18:16:14 UTC
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."

Comment 41 Lennart Poettering 2015-06-08 18:27:25 UTC
Also, see:

https://github.com/systemd/systemd/pull/85#issuecomment-110098645

Comment 42 Stephen Smalley 2015-06-08 19:09:31 UTC
(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.

Comment 43 Simon McVittie 2015-06-09 11:18:51 UTC
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.

Comment 44 Zbigniew Jędrzejewski-Szmek 2015-06-09 16:24:32 UTC
*** Bug 1229573 has been marked as a duplicate of this bug. ***

Comment 45 Jakub Filak 2015-06-10 07:46:40 UTC
*** Bug 1230035 has been marked as a duplicate of this bug. ***

Comment 46 Stephen Smalley 2015-06-10 13:19:22 UTC
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.

Comment 47 Zbigniew Jędrzejewski-Szmek 2015-06-10 17:32:30 UTC
http://cgit.freedesktop.org/systemd/systemd/commit/?id=b078b5a7ab

Comment 48 Stephen Smalley 2015-06-11 12:58:16 UTC
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.

Comment 49 Morten Stevens 2015-06-11 13:13:42 UTC
(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.

Comment 50 dominique 2015-06-11 14:07:58 UTC
Thank.
systemd-220-8.fc23 solve for me  bug: 1229573

Comment 51 Paul Moore 2015-06-11 14:28:17 UTC
(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.

Comment 52 Steevithak 2015-09-17 23:45:26 UTC
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!

Comment 53 Steevithak 2015-09-17 23:52:29 UTC
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.

Comment 54 Konstantin Ryabitsev 2015-09-18 12:08:50 UTC
Seems like this bug made it into Fedora 22 with systemd-219-24.fc22.x86_64 -- impossible to shutdown the system.

Comment 55 Stephen Smalley 2015-09-18 16:14:19 UTC
Do you have any output from ausearch -m AVC,USER_AVC,SELINUX_ERR -ts recent?

Comment 56 thestonewell 2015-09-18 18:03:56 UTC
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=?'

Comment 57 Stephen Smalley 2015-09-18 18:11:16 UTC
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?

Comment 58 thestonewell 2015-09-18 18:38:24 UTC
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?

Comment 59 Stephen Smalley 2015-09-18 18:44:39 UTC
Wait, you said that only updated selinux-policy-targeted, not systemd?
What versions of each?

Comment 60 Stephen Smalley 2015-09-18 18:58:39 UTC
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.

Comment 61 thestonewell 2015-09-18 19:03:51 UTC
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!

Comment 62 Stephen Smalley 2015-09-18 19:41:41 UTC
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.

Comment 63 Stephen Smalley 2015-09-18 19:43:01 UTC
Created attachment 1075041 [details]
Trivial program to demonstrate failure after policy update

Comment 64 Steevithak 2015-09-18 20:08:27 UTC
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.

Comment 65 Kevin Fenzi 2015-09-18 20:13:03 UTC
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

Comment 66 Miroslav Grepl 2015-09-21 07:20:30 UTC
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

Comment 67 Daniel Walsh 2015-09-21 12:10:02 UTC
Could you add a trigger to systemctl daemon-rexec on older selinux-policy?

Comment 68 Miroslav Grepl 2015-09-21 21:11:22 UTC
(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.

Comment 69 Miroslav Grepl 2015-09-22 09:02:58 UTC
I think we should do that ordinarily in %post. Does it make sense for you guys?

Comment 70 Daniel Walsh 2015-09-22 13:03:37 UTC
The real fix would be to have systemd realize it happened and reload its own policy.

Comment 71 Stephen Smalley 2015-09-22 13:22:50 UTC
The class/perm mappings are cached by libselinux; systemd doesn't even know about them.

Comment 72 Daniel Walsh 2015-09-22 18:13:30 UTC
I thought libselinux/systemd can realize when the policy has been updated and dump its cache?

Comment 73 Stephen Smalley 2015-09-22 18:14:52 UTC
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).

Comment 74 Igor Bukanov 2015-09-23 12:19:14 UTC
The bug propagated to Fedora 22 after today update. Should a new bug be opened for that?

Comment 75 Thorsten Kohfeldt 2015-09-24 14:57:25 UTC
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

Comment 76 Thorsten Kohfeldt 2015-09-24 17:26:50 UTC
And yes,

systemctl daemon-reexec

also works and is even faster ...

Comment 77 Miroslav Grepl 2015-09-24 19:11:00 UTC
(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.

Comment 78 Thorsten Kohfeldt 2015-09-24 19:47:11 UTC
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".

Comment 79 François Kooman 2015-09-28 07:51:36 UTC
*** Bug 1263570 has been marked as a duplicate of this bug. ***

Comment 80 Adam Williamson 2015-09-28 15:57:17 UTC
Thorsten: it should, because the change made was to run systemctl daemon-reexec in selinux-policy %post.

Comment 81 Miroslav Grepl 2015-10-01 10:01:27 UTC
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.


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