Zerotier failing to start after upgrade
-
I have a Fedora server running a Zerotier client. I just upgraded the Zerotier client using the Cockpit Software update tool. Now, SELinux is preventing Zerotier from starting.
Checking out the logs, I see this:
SELinux is preventing zerotier-one from mmap_zero access on the memprotect labeled unconfined_service_t. For complete SELinux messages run: sealert -l 1f1ceca4-4863-4718-8ea1-842c896efe6f PRIORITY 3 SYSLOG_FACILITY 1 SYSLOG_IDENTIFIER setroubleshoot SYSLOG_TIMESTAMP Aug 13 15:12:01 _BOOT_ID 1db18015b13144c39b724c150496bd4c _CAP_EFFECTIVE 0 _CMDLINE /usr/bin/python3 -Es /usr/sbin/setroubleshootd -f _COMM setroubleshootd _EXE /usr/bin/python3.7 _GID 989 _HOSTNAME kvm02 _MACHINE_ID 37a3158c54a94f95933347d75a31328c _PID 2442 _SELINUX_CONTEXT system_u:system_r:setroubleshootd_t:s0 _SOURCE_REALTIME_TIMESTAMP 1565723521479884 _SYSTEMD_CGROUP /system.slice/system-dbus\x2d:1.4\x2dorg.fedoraproject.Setroubleshootd.slice/dbus-:[email protected] _SYSTEMD_INVOCATION_ID b5310f7b1de54762b5d1b39b6760301c _SYSTEMD_SLICE system-dbus\x2d:1.4\x2dorg.fedoraproject.Setroubleshootd.slice _SYSTEMD_UNIT dbus-:[email protected] _TRANSPORT syslog _UID 993 __CURSOR s=efc0715fcccc4f67927d76898bd0babd;i=fa28;b=1db18015b13144c39b724c150496bd4c;m=89855ecd;t=590046a507500;x=ac7e3f5882c8542f __MONOTONIC_TIMESTAMP 2307219149 __REALTIME_TIMESTAMP 1565723521479936Any ideas?
-
@fuznutz04
What's the output of
sealert -l 1f1ceca4-4863-4718-8ea1-842c896efe6f? -
@DustinB3403 said in Zerotier failing to start after upgrade:
sealert -l 1f1ceca4-4863-4718-8ea1-842c896efe6f
sealert -l 1f1ceca4-4863-4718-8ea1-842c896efe6f /usr/bin/sealert:32: DeprecationWarning: Importing dbus.glib to use the GLib main loop with dbus-python is deprecated. Instead, use this sequence: from dbus.mainloop.glib import DBusGMainLoop DBusGMainLoop(set_as_default=True) import dbus.glib SELinux is preventing zerotier-one from mmap_zero access on the memprotect labeled unconfined_service_t. ***** Plugin mmap_zero (53.1 confidence) suggests ************************* If you do not think zerotier-one should need to mmap low memory in the kernel. Then you may be under attack by a hacker, this is a very dangerous access. Do contact your security administrator and report this issue. ***** Plugin catchall_boolean (42.6 confidence) suggests ****************** If you want to allow mmap to low allowed Then you must tell SELinux about this by enabling the 'mmap_low_allowed' boolean. Do setsebool -P mmap_low_allowed 1 ***** Plugin catchall (5.76 confidence) suggests ************************** If you believe that zerotier-one should be allowed mmap_zero access on memprotect labeled unconfined_service_t by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'zerotier-one' --raw | audit2allow -M my-zerotierone # semodule -X 300 -i my-zerotierone.pp Additional Information: Source Context system_u:system_r:unconfined_service_t:s0 Target Context system_u:system_r:unconfined_service_t:s0 Target Objects Unknown [ memprotect ] Source zerotier-one Source Path zerotier-one Port <Unknown> Host kvm02 Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.14.3-43.fc30.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name kvm02 Platform Linux kvm02 5.2.7-200.fc30.x86_64 #1 SMP Thu Aug 8 05:35:29 UTC 2019 x86_64 x86_64 Alert Count 6 First Seen 2019-08-13 15:11:56 EDT Last Seen 2019-08-13 15:11:58 EDT Local ID 1f1ceca4-4863-4718-8ea1-842c896efe6f Raw Audit Messages type=AVC msg=audit(1565723518.1:334): avc: denied { mmap_zero } for pid=2703 comm="zerotier-one" scontext=system_u:system_r:unconfined_service_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=memprotect permissive=0 Hash: zerotier-one,unconfined_service_t,unconfined_service_t,memprotect,mmap_zero -
@fuznutz04 Looks like the answer is in the details.
Either you can allow
nmap_low_allowedor you can allow it anyways with 2 or you can report it as a bug.setsebool -P mmap_low_allowed 1
or
-
ausearch -c 'zerotier-one' --raw | audit2allow -M my-zerotierone
semodule -X 300 -i my-zerotierone.pp -
Report it as a bug.
-
@DustinB3403 said in Zerotier failing to start after upgrade:
semodule -X 300 -i my-zerotierone.pp
Thanks Dustin. That did the trick!
-
no zerotier adapter on my laptop
this is bad juju
-
This is definitely a bad deal. Anyone know if it has been reported to ZeroTier?
All better, but only on my laptop. All the remote systems with SELinux are going to be under the same problem.
-
Just confirmed. This also affects CentOS 7.
-
@JaredBusch said in Zerotier failing to start after upgrade:
Anyone know if it has been reported to ZeroTier?
Not sure, it was 1 of the 3 recommendations I made to @fuznutz04
-
Do an update. We released new binary builds for Linux that should address this.
-
@adam-ierymenko said in Zerotier failing to start after upgrade:
Do an update. We released new binary builds for Linux that should address this.
Yep, its working.
-
@adam-ierymenko said in Zerotier failing to start after upgrade:
Do an update. We released new binary builds for Linux that should address this.
Awesome
-
@adam-ierymenko said in Zerotier failing to start after upgrade:
Do an update. We released new binary builds for Linux that should address this.
Awesome, Thanks!
-
@adam-ierymenko said in Zerotier failing to start after upgrade:
Do an update. We released new binary builds for Linux that should address this.
Awesome, except all of my stuff alreadfy updated and is offline.
So I'm stuck for up to 24 hours until dnf-automatic rolls again. -
can the mac version be updated via
zerotier-cliat all? -
@adam-ierymenko said in Zerotier failing to start after upgrade:
Do an update. We released new binary builds for Linux that should address this.
Sorry for resurrecting an old thread, but new installs are having the same selinux issue. Took some digging for me to figure out what was going on. Multiple attempts to install on Fedora 33.
