Description of problem: # semanage fcontext -l | grep arping /sbin/arping regular file system_u:object_r:netutils_exec_t:s0 /usr/sbin/arping regular file system_u:object_r:netutils_exec_t:s0 # ls -iZ /sbin/arping 8925261 system_u:object_r:bin_t:s0 /sbin/arping # ls -iZ /usr/sbin/arping 8925261 system_u:object_r:bin_t:s0 /usr/sbin/arping # ls -iZ /bin/arping 2240758 system_u:object_r:bin_t:s0 /bin/arping # ls -iZ /sbin/arping 8925261 system_u:object_r:bin_t:s0 /sbin/arping # Version-Release number of selected component (if applicable): iputils-20190515-5.fc32.x86_64 selinux-policy-3.14.5-32.fc32.noarch selinux-policy-devel-3.14.5-32.fc32.noarch selinux-policy-doc-3.14.5-32.fc32.noarch selinux-policy-minimum-3.14.5-32.fc32.noarch selinux-policy-mls-3.14.5-32.fc32.noarch selinux-policy-sandbox-3.14.5-32.fc32.noarch selinux-policy-targeted-3.14.5-32.fc32.noarch How reproducible: * always Actual results: * none of the arping files is labeled netutils_exec_t Expected results: * the arping file (which is NOT a symlink) is labeled netutils_exec_t
The comment#0 contains a duplicate location. Here are all possible locations without duplicates: # ls -iZ /sbin/arping 8925261 system_u:object_r:bin_t:s0 /sbin/arping # ls -iZ /usr/sbin/arping 8925261 system_u:object_r:bin_t:s0 /usr/sbin/arping # ls -iZ /bin/arping 2240758 system_u:object_r:bin_t:s0 /bin/arping # ls -iZ /usr/bin/arping 2240758 system_u:object_r:bin_t:s0 /usr/bin/arping # None of them is labeled correctly.
Milosi, Thank you for reporting. It seems to be okay in F30, but not in later releases. Looks like the binary moved from sbin to bin somewhere between iputils-20180629 and iputils-20190515, with a symlink for compatibility. So the sbin one now seems to be labeled correctly, but label for bin/arping needs to be added to the policy. This is what I can see on a clean installation: # ls -liZ /usr/sbin/arping /usr/bin/arping 2393024 -rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 36224 Feb 3 13:23 /usr/bin/arping 2422957 lrwxrwxrwx. 1 root root system_u:object_r:bin_t:s0 13 Feb 3 13:23 /usr/sbin/arping -> ../bin/arping # rpm -qf /usr/sbin/arping /usr/bin/arping iputils-20190515-5.fc32.x86_64 iputils-20190515-5.fc32.x86_64 # matchpathcon /usr/sbin/arping /usr/bin/arping /usr/sbin/arping system_u:object_r:bin_t:s0 /usr/bin/arping system_u:object_r:bin_t:s0
I've submitted a Fedora PR to address the issue: https://github.com/fedora-selinux/selinux-policy/pull/341
Fixed in Fedora: commit dad6a809df19a66c66b43cf0684671a806d872dd (HEAD -> rawhide, origin/rawhide) Author: Zdenek Pytela <zpytela> Date: Fri Apr 3 09:38:33 2020 +0200 Modify path for arping in netutils.fc to match both bin and sbin In iputils newer than iputils-20180629 the arping command moved from /sbin to /bin, hence the path in the netutils.fc file needs to be adjusted so that it matches both possible paths for the actual file. Symlink can have bin_t assigned. Resolves: rhbz#1820191
FEDORA-2020-2fad1f552d has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-2fad1f552d
FEDORA-2020-2fad1f552d has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-2fad1f552d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-2fad1f552d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.