On both and F27 and F28 system (I'm testing with clean default installs from the Server netinst), this acts as expected: [root@localhost ~]# getsebool httpd_can_network_connect httpd_can_network_connect --> off [root@localhost ~]# setsebool -P httpd_can_network_connect on [root@localhost ~]# getsebool httpd_can_network_connect httpd_can_network_connect --> on (reboot system) [root@localhost ~]# getsebool httpd_can_network_connect httpd_can_network_connect --> on so, that's fine, we set a boolean permanently. But now, try upgrading the F27 system to F28: [root@localhost ~]# dnf system-upgrade download --releasever=28 [root@localhost ~]# dnf system-upgrade reboot ... upgrade occurs, libselinux upgraded to 2.7-11.fc28, selinux-policy-targeted to 3.14.1-14.fc28, audit is *downgraded* to 2.8.2-4.fc28 (from 2.8.3-1.fc27). After upgrade is complete, boot and log in as root again: [root@localhost ~]# getsebool httpd_can_network_connect httpd_can_network_connect --> off [root@localhost ~]# setsebool -P httpd_can_network_connect on libsepol.context_from_record: type conntrackd_var_run_t is not defined libsepol.context_from_record: could not create context structure libsepol.context_from_string: could not create context structure libsepol.sepol_context_to_sid: could not convert system_u:object_r:conntrackd_var_run_t:s0 to sid invalid context system_u:object_r:conntrackd_var_run_t:s0 [root@localhost ~]# reboot After reboot: [root@localhost ~]# getsebool httpd_can_network_connect httpd_can_network_connect --> off So basically, on upgrade from F27 to F28, any *existing* local permanent boolean changes are lost, and doing *new* permanent boolean changes no longer works properly: errors are printed, and even with -P, the change takes effect only until reboot, it is lost on the next boot. This breaks the FreeIPA web UI (and likely other bits of FreeIPA) on upgrade from F27 to F28, so proposing as a Beta blocker. There *is* a workaround - change the boolean manually on each boot - but it's kinda sucky.
Note also this, during the system upgrade transaction itself: Mar 21 14:26:02 localhost.localdomain dnf[734]: Upgrading : selinux-policy-targeted-3.14.1-14.fc28.noarch 483/1176 Mar 21 14:26:04 localhost.localdomain kernel: SELinux: 32768 avtab hash slots, 112648 rules. Mar 21 14:26:04 localhost.localdomain kernel: SELinux: 32768 avtab hash slots, 112648 rules. Mar 21 14:26:04 localhost.localdomain kernel: SELinux: 8 users, 14 roles, 5102 types, 315 bools, 1 sens, 1024 cats Mar 21 14:26:04 localhost.localdomain kernel: SELinux: 129 classes, 112648 rules Mar 21 14:26:04 localhost.localdomain kernel: SELinux: Class bpf not defined in policy. Mar 21 14:26:04 localhost.localdomain kernel: SELinux: the above unknown classes and permissions will be allowed Mar 21 14:26:04 localhost.localdomain kernel: SELinux: policy capability network_peer_controls=1 Mar 21 14:26:04 localhost.localdomain kernel: SELinux: policy capability open_perms=1 Mar 21 14:26:04 localhost.localdomain kernel: SELinux: policy capability extended_socket_class=1 Mar 21 14:26:04 localhost.localdomain kernel: SELinux: policy capability always_check_network=0 Mar 21 14:26:04 localhost.localdomain kernel: SELinux: policy capability cgroup_seclabel=1 Mar 21 14:26:04 localhost.localdomain kernel: SELinux: policy capability nnp_nosuid_transition=1 Mar 21 14:26:04 localhost.localdomain audit[736]: USER_AVC pid=736 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: received policyload notice (seqno=2) exe=2F7573722F62696E2F646275732D6461656D6F6E202864656C6574656429 sauid=81 hostname=? addr=? terminal=?' Mar 21 14:26:04 localhost.localdomain kernel: audit: type=1107 audit(1521667564.898:102): pid=736 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: received policyload notice (seqno=2) exe=2F7573722F62696E2F646275732D6461656D6F6E202864656C6574656429 sauid=81 hostname=? addr=? terminal=?' Mar 21 14:26:04 localhost.localdomain audit: MAC_POLICY_LOAD policy loaded auid=4294967295 ses=4294967295 Mar 21 14:26:04 localhost.localdomain audit[2901]: SYSCALL arch=c000003e syscall=1 success=yes exit=8150158 a0=4 a1=7f43fb978000 a2=7c5c8e a3=0 items=0 ppid=2897 pid=2901 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="load_policy" exe="/usr/sbin/load_policy" subj=system_u:system_r:load_policy_t:s0 key=(null) Mar 21 14:26:04 localhost.localdomain kernel: audit: type=1403 audit(1521667564.550:103): policy loaded auid=4294967295 ses=4294967295 Mar 21 14:26:04 localhost.localdomain kernel: audit: type=1300 audit(1521667564.550:103): arch=c000003e syscall=1 success=yes exit=8150158 a0=4 a1=7f43fb978000 a2=7c5c8e a3=0 items=0 ppid=2897 pid=2901 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="load_policy" exe="/usr/sbin/load_policy" subj=system_u:system_r:load_policy_t:s0 key=(null) Mar 21 14:26:04 localhost.localdomain kernel: audit: type=1327 audit(1521667564.550:103): proctitle="load_policy" Mar 21 14:26:04 localhost.localdomain audit: PROCTITLE proctitle="load_policy" Mar 21 14:26:04 localhost.localdomain dbus-daemon[736]: [system] Reloaded configuration Mar 21 14:26:05 localhost.localdomain dnf[734]: Running scriptlet: selinux-policy-targeted-3.14.1-14.fc28.noarch 483/1176 Mar 21 14:26:05 localhost.localdomain dnf[734]: Re-declaration of typealias ganesha_var_log_t Mar 21 14:26:05 localhost.localdomain dnf[734]: Failed to create node Mar 21 14:26:05 localhost.localdomain dnf[734]: Bad typealias declaration at /var/lib/selinux/targeted/tmp/modules/100/glusterd/cil:1 Mar 21 14:26:05 localhost.localdomain dnf[734]: /usr/sbin/semodule: Failed!
I really don't want to, but I'm also +1 blocker here, mostly on the grounds that if SELinux booleans are misbehaving this badly after an upgrade, there are probably even more insidious effects waiting to creep up on us.
Guys, It looks like issue is in policycoreutils: # semanage boolean -l | grep httpd_can_network_connect httpd_can_network_connect (off , off) Allow HTTPD scripts and modules to connect to the network using TCP. # semanage boolean -m --on httpd_can_network_connect # # semanage boolean -l | grep httpd_can_network_connect httpd_can_network_connect (off , on) Allow HTTPD scripts and modules to connect to the network using TCP. So, not actual state but only default value is changed. To fix it we need to use setsebool. # setsebool -P httpd_can_network_connect=1 # # semanage boolean -l | grep httpd_can_network_connect httpd_can_network_connect (on , on) Allow HTTPD scripts and modules to connect to the network using TCP.
+1 for the blocker. Lukas tells me there is a fix already.
https://github.com/fedora-selinux/selinux/commit/63b18604d4bf020ca5cd7781ecf8c0e0443e02d1
Discussed during blocker review [1]: AcceptedBlocker (Beta) - accepted as a violation of the upgrade criteria applied to release-blocking server roles (as noted in the bug) [1] https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2018-03-22/
libsepol-2.7-6.fc28 libselinux-2.7-13.fc28 libsemanage-2.7-12.fc28 checkpolicy-2.7-7.fc28 policycoreutils-2.7-17.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-08531132c6
I built an update with the policycoreutils that's claimed to fix this - see above. Testing shows absolutely no apparent difference, though. Running the exact same test - but with a side repository containing the packages from the update included in the upgrade, so the upgraded system gets policycoreutils-2.7-17.fc28 - behaves *exactly* the same. I note that the changed file - seobject.py - is part of policycoreutils-python-utils . This package is not even *installed* in the test scenario, so I find it hard to see how a change to that file could possibly fix the bug.
BTW, the fix is also technically wrong. Instances of the empty string are not guaranteed to have the same identity in Python. As a current implementation of CPython, they usually do, but this is not a guaranteed feature of the language. Basically, `"" is ""` is not guaranteed to be True. You should use 'if not self.store'.
(In reply to Adam Williamson from comment #8) > I note that the changed file - seobject.py - is part of > policycoreutils-python-utils . This package is not even *installed* in the > test scenario, so I find it hard to see how a change to that file could > possibly fix the bug. seobject.py is part of python[23]-policycoreutils: ^&^ find /usr/ -name seobject.py | xargs rpm -qf python2-policycoreutils-2.7-17.fc28.noarch python3-policycoreutils-2.7-17.fc28.noarch (In reply to Adam Williamson from comment #8) > I built an update with the policycoreutils that's claimed to fix this - see > above. Testing shows absolutely no apparent difference, though. Running the > exact same test - but with a side repository containing the packages from > the update included in the upgrade, so the upgraded system gets > policycoreutils-2.7-17.fc28 - behaves *exactly* the same. > The problem described in https://bugzilla.redhat.com/show_bug.cgi?id=1559174#c3 seems to be fixed: [root@fedora28 ~]# rpm -qf /usr/sbin/semanage policycoreutils-python-utils-2.7-17.fc28.noarch [root@fedora28 ~]# semanage boolean -l | grep "httpd_can_network_connect " httpd_can_network_connect (on , on) Allow HTTPD scripts and modules to connect to the network using TCP. [root@fedora28 ~]# semanage boolean -m --off httpd_can_network_connect [root@fedora28 ~]# semanage boolean -l | grep "httpd_can_network_connect " httpd_can_network_connect (off , off) Allow HTTPD scripts and modules to connect to the network using TCP. [root@fedora28 ~]# semanage boolean -m --on httpd_can_network_connect [root@fedora28 ~]# semanage boolean -l | grep "httpd_can_network_connect " httpd_can_network_connect (on , on) Allow HTTPD scripts and modules to connect to the network using TCP. (In reply to Adam Williamson from comment #9) > BTW, the fix is also technically wrong. Instances of the empty string are > not guaranteed to have the same identity in Python. As a current > implementation of CPython, they usually do, but this is not a guaranteed > feature of the language. Basically, `"" is ""` is not guaranteed to be True. > You should use 'if not self.store'. Good point. I'll update the patch
policycoreutils-2.7-6.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-7535a8e21e
"seobject.py is part of python[23]-policycoreutils:" Yes. And neither of those is installed in the test scenario. A default Fedora 27 Server install includes neither, and neither is installed on upgrade. The package called 'policycoreutils' is installed, but none of its subpackages are. "The problem described in https://bugzilla.redhat.com/show_bug.cgi?id=1559174#c3 seems to be fixed:" Maybe it is, but that's not the problem I filed the bug on. I filed the bug on use of setsebool, and that is still broken *precisely* as described in the initial description. I re-ran the entire test (with the update included) and it behaved precisely the same as before. Note, semanage is not installed either before or after the upgrade. https://bodhi.fedoraproject.org/updates/FEDORA-2018-7535a8e21e seems very unlikely to fix this bug, as it's an F27 update. The issue occurs on upgrade to F28.
policycoreutils-2.7-6.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-7535a8e21e
Ok, my original statement and the update was based on wrong suggestions. Lets start from beginning. I'm able to reproduce this problem using updated f27 and # dnf update selinux-policy --releasever=28 There's an error during the transactions and I think this is can be a clue: Upgrading : selinux-policy-targeted-3.14.1-14.fc28.noarch 2/10 Running scriptlet: selinux-policy-targeted-3.14.1-14.fc28.noarch 2/10 Re-declaration of typealias ganesha_var_log_t Failed to create node Bad typealias declaration at /var/lib/selinux/targeted/tmp/modules/100/glusterd/cil:1 /usr/sbin/semodule: Failed! After the update, the problem with setsebool appears: # getsebool httpd_can_network_connect httpd_can_network_connect --> on # setsebool -P httpd_can_network_connect off libsepol.context_from_record: type conntrackd_var_run_t is not defined libsepol.context_from_record: could not create context structure libsepol.context_from_string: could not create context structure libsepol.sepol_context_to_sid: could not convert system_u:object_r:conntrackd_var_run_t:s0 to sid invalid context system_u:object_r:conntrackd_var_run_t:s0 # getsebool httpd_can_network_connect When I rebuild the policy, it's gone: # semodule -B # getsebool httpd_can_network_connect httpd_can_network_connect --> off # setsebool -P httpd_can_network_connect on # getsebool httpd_can_network_connect httpd_can_network_connect --> on
Additional notes: In Fedora 28 ganesha SELinux module is dropped. But since 'semodule -B -n -s targeted' is called in %post phase of selinux-policy-targeted, the ganesha module is still on the file system (an old selinux-policy-targeted hasn't been removed yet) and it causes the problem with 'Re-declaration of typealias ganesha_var_log_t' and leaves the system policy store in a state that it needs to be rebuilt again. 3 possible workarounds: 1. disable 'ganesha' module before update semodule -d ganesha 2. rebuild policy after update semodule -B 3. move steps from %post to %postrans in selinux-policy.spec
*** Bug 1556787 has been marked as a duplicate of this bug. ***
I disabled ganesha module during pre install phase of selinux-policy package. Already building the package.
*** Bug 1558816 has been marked as a duplicate of this bug. ***
Petr: Note that I posted precisely those error messages in the description and in comment #1. Thanks for the fix.
selinux-policy-3.14.1-17.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-b8cb71b345
selinux-policy-3.14.1-17.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-b8cb71b345
Description of problem: This may be related to enabling dbus-broker as the system D-BUS implementation. Version-Release number of selected component: selinux-policy-3.14.1-14.fc28.noarch Additional info: reporter: libreport-2.9.3 hashmarkername: setroubleshoot kernel: 4.16.0-0.rc6.git0.2.fc28.x86_64 type: libreport
(In reply to Stephen Gallagher from comment #22) > Description of problem: > This may be related to enabling dbus-broker as the system D-BUS > implementation. > > Version-Release number of selected component: > selinux-policy-3.14.1-14.fc28.noarch > > Additional info: > reporter: libreport-2.9.3 > hashmarkername: setroubleshoot > kernel: 4.16.0-0.rc6.git0.2.fc28.x86_64 > type: libreport Note: the description above was made before I knew which BZ it was going to match. Clearly this is inaccurate.
How on earth did libreport link it to this bug anyway? I filed this bug manually and it doesn't appear to have any magic metadata markers. /me looks around suspiciously
(In reply to Adam Williamson from comment #24) > How on earth did libreport link it to this bug anyway? I filed this bug > manually and it doesn't appear to have any magic metadata markers. /me looks > around suspiciously I suspect it matched BZ #1558816 which was marked as a duplicate of this bug.
selinux-policy-3.14.1-18.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-7821b2e7c4
selinux-policy-3.14.1-18.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.
policycoreutils-2.7-6.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.