Description of problem: The SELinux denial indicates that the hostname process, running within the cockpit_ws_t domain, is being blocked from performing a "search" operation on a directory classified as sysctl_net_t. This type of directory likely holds networking configuration information. Here's a breakdown of the situation: SELinux is in Enforcing mode: This means security policies are actively preventing unauthorized actions. Process Affected: The hostname command is being blocked, likely when trying to obtain network configuration details. Cockpit Connection: The cockpit_ws_t domain suggests the hostname command might be executed from within the Cockpit web-based management interface. Concise Evaluation The SELinux denial is likely a result of a missing or overly restrictive policy for the Cockpit service. The default SELinux configuration might not anticipate that Cockpit would need to execute the hostname command to gather network information. SELinux is preventing hostname from 'search' accesses on the directory net. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that hostname should be allowed search access on the net directory 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 'hostname' --raw | audit2allow -M my-hostname # semodule -X 300 -i my-hostname.pp Additional Information: Source Context system_u:system_r:cockpit_ws_t:s0 Target Context system_u:object_r:sysctl_net_t:s0 Target Objects net [ dir ] Source hostname Source Path hostname Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-39.5-1.fc39.noarch Local Policy RPM cockpit-ws-314-1.fc39.x86_64 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 6.8.4-200.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Apr 4 20:45:21 UTC 2024 x86_64 Alert Count 2 First Seen 2024-04-12 14:33:51 EDT Last Seen 2024-04-12 14:33:51 EDT Local ID bba3c3d3-5905-4f43-b2f9-23f7865984e7 Raw Audit Messages type=AVC msg=audit(1712946831.10:194): avc: denied { search } for pid=4800 comm="hostname" name="net" dev="proc" ino=6267 scontext=system_u:system_r:cockpit_ws_t:s0 tcontext=system_u:object_r:sysctl_net_t:s0 tclass=dir permissive=0 Hash: hostname,cockpit_ws_t,sysctl_net_t,dir,search Version-Release number of selected component: selinux-policy-targeted-39.5-1.fc39.noarch Additional info: reporter: libreport-2.17.11 reason: SELinux is preventing hostname from 'search' accesses on the directory net. package: selinux-policy-targeted-39.5-1.fc39.noarch component: cockpit hashmarkername: setroubleshoot type: libreport kernel: 6.8.4-200.fc39.x86_64 component: cockpit Potential duplicate: bug 2143070
Created attachment 2026672 [details] File: description
Created attachment 2026673 [details] File: os_info
This avc started happening weeks ago when I was on F38, but I just upgrade to F39 and it's still happening every time I boot my desktop. package: selinux-policy-targeted-39.7-1.fc39.noarch type: libreport hashmarkername: setroubleshoot reason: SELinux is preventing hostname from 'search' accesses on the directory net. comment: This avc started happening weeks ago when I was on F38, but I just upgrade to F39 and it's still happening every time I boot my desktop. kernel: 6.8.11-200.fc39.x86_64
The source domain in the report is defined in cockpit-selinux, so should be addressed there, either with kernel_search_network_sysctl(cockpit_ws_t) or with allowing more permissions.
@tye7354 thanks for your report. This was already reported before, in bug 2243194 and bug 2143070. I still don't understand what happens, and we never see this anywhere in our CI either. This can realistically come from only two places, as these are the only ones where /usr/bin/hostname is called in cockpit: - /usr/share/cockpit/motd/update-motd calls hostname, this is invoked through cockpit-motd.service. But that doesn't run in cockpit_ws_t context, it's an independent unit. - /usr/libexec/cockpit-certificate-helper (invoked from cockpit.service via cockpit-certificate-ensure) calls hostname if sscg is not installed. But this is only called when using cockpit the first time, and neither this report nor the duplicate #2143403 sound like that. Therefore, can you please attach a full `journalctl -b > /tmp/journal.txt` from a run where this happens? If you know what I'm talking about, it would also help a lot if you could add a "set -x" near the top of both /usr/share/cockpit/motd/update-motd and /usr/libexec/cockpit-certificate-helper , reboot, capture a journal again, and then revert the change. This may shed some more light on what happens. If this sounds dubious to you, nevermind -- I can talk you through it if the initial journal doesn't help enough. Thanks!
I no longer have this system, however I am going to attempt to replicate the issue by pulling a docker image, I will also look into this set -x to further understand why and work on the bug. I am new to this. I apologize if my bug report was not detailed enough.
Created attachment 2054635 [details] journal.txt (In reply to Martin Pitt from comment #5) > @tye7354 thanks for your report. This was already reported before, > in bug 2243194 and bug 2143070. I still don't understand what happens, and > we never see this anywhere in our CI either. > > This can realistically come from only two places, as these are the only ones > where /usr/bin/hostname is called in cockpit: > > - /usr/share/cockpit/motd/update-motd calls hostname, this is invoked > through cockpit-motd.service. But that doesn't run in cockpit_ws_t context, > it's an independent unit. > > - /usr/libexec/cockpit-certificate-helper (invoked from cockpit.service via > cockpit-certificate-ensure) calls hostname if sscg is not installed. But > this is only called when using cockpit the first time, and neither this > report nor the duplicate #2143403 sound like that. > > Therefore, can you please attach a full `journalctl -b > /tmp/journal.txt` > from a run where this happens? Here's the requested journal.txt where the error is present.
Coacher: I'm afraid that initial journal doesn't show anything new. The only messages are the two avc denials, but it doesn't show what pid 1088 is, or which unit it belongs to. If you could add the two `set -x` from comment #5, that'd be great. Thanks!
(In reply to Martin Pitt from comment #8) > Coacher: I'm afraid that initial journal doesn't show anything new. The only > messages are the two avc denials, but it doesn't show what pid 1088 is, or > which unit it belongs to. If you could add the two `set -x` from comment #5, > that'd be great. Thanks! I've made the requested change. Will post back when the problem reoccurs.
Created attachment 2056994 [details] journal.txt (In reply to Martin Pitt from comment #8) > Coacher: I'm afraid that initial journal doesn't show anything new. The only > messages are the two avc denials, but it doesn't show what pid 1088 is, or > which unit it belongs to. If you could add the two `set -x` from comment #5, > that'd be great. Thanks! Error: type=AVC msg=audit(11.11.2024 09:46:11.741:101) : avc: denied { search } for pid=1072 comm=hostname name=net dev="proc" ino=1486 scontext=system_u:system_r:cockpit_ws_t:s0 tcontext=system_u:object_r:sysctl_net_t:s0 tclass=dir permissive=0 ---- type=AVC msg=audit(11.11.2024 09:46:11.741:102) : avc: denied { search } for pid=1072 comm=hostname name=net dev="proc" ino=1486 scontext=system_u:system_r:cockpit_ws_t:s0 tcontext=system_u:object_r:sysctl_net_t:s0 tclass=dir permissive=0 I've attached the output of `journalctl -b -o short-precise`
This message is a reminder that Fedora Linux 39 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-26. 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 'version' of '39'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 39 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 Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Thanks Coacher! So this confirms it comes from /usr/share/cockpit/motd/update-motd via cockpit-motd.service. My earlier observation is wrong: > - /usr/share/cockpit/motd/update-motd calls hostname, this is invoked through cockpit-motd.service. But that doesn't run in cockpit_ws_t context, it's an independent unit. Our selinux/cockpit.fc *does* assign cockpit_ws_exec_t to the update-motd script. It wouldn't have to (these are independent), but that's the status quo. Our policy already does optional_policy(` hostname_exec(cockpit_ws_t) ') but apparently that doesn't allow searching /proc. As this doesn't happen in a default Fedora install (either if /etc/hostname is present or absent), I suspect you have some custom /etc/nsswitch.conf or whatever else it could be that makes `hostname` trigger a /proc search. As I can't reproduce this at all, my preferred approach is to just fix the ownership. I did that in https://github.com/cockpit-project/cockpit/pull/21332 Would you be able to test that? You can install cockpit-ws from this COPR: https://copr.fedorainfracloud.org/coprs/packit/cockpit-project-cockpit-21332/ sudo dnf copr enable packit/cockpit-project-cockpit-21332 sudo dnf distro-sync --repo='copr*' cockpit-ws which should install cockpit-ws-329-1.20241126092504522023.pr21332. Thanks!
(In reply to Martin Pitt from comment #12) > Thanks Coacher! So this confirms it comes from > /usr/share/cockpit/motd/update-motd via cockpit-motd.service. My earlier > observation is wrong: > > > - /usr/share/cockpit/motd/update-motd calls hostname, this is invoked through cockpit-motd.service. But that doesn't run in cockpit_ws_t context, it's an independent unit. > > Our selinux/cockpit.fc *does* assign cockpit_ws_exec_t to the update-motd > script. It wouldn't have to (these are independent), but that's the status > quo. > > Our policy already does > > optional_policy(` > hostname_exec(cockpit_ws_t) > ') > > but apparently that doesn't allow searching /proc. As this doesn't happen in > a default Fedora install (either if /etc/hostname is present or absent), I > suspect you have some custom /etc/nsswitch.conf or whatever else it could be > that makes `hostname` trigger a /proc search. > > As I can't reproduce this at all, my preferred approach is to just fix the > ownership. I did that in > https://github.com/cockpit-project/cockpit/pull/21332 > > Would you be able to test that? You can install cockpit-ws from this COPR: > https://copr.fedorainfracloud.org/coprs/packit/cockpit-project-cockpit-21332/ > > > sudo dnf copr enable packit/cockpit-project-cockpit-21332 > sudo dnf distro-sync --repo='copr*' cockpit-ws > > which should install cockpit-ws-329-1.20241126092504522023.pr21332. > > Thanks! I don't know a way to reproduce this bug, so I cannot test this change. Since you know cockpit internals better than me, could you please provide a testing scenario?
Coacher: Sorry, I can't. As I wrote I could never actually get this SELinux violation, so I asked for `set -x` and journal debug info. Then my proposal is, I'll close this bug with the next upload (that contains the fix), and we'll let users report a new one if something similar still happens again (it can't be the same violation any more due to the change in https://github.com/cockpit-project/cockpit/pull/21332)
(In reply to Martin Pitt from comment #14) > Coacher: Sorry, I can't. As I wrote I could never actually get this SELinux > violation, so I asked for `set -x` and journal debug info. Then my proposal > is, I'll close this bug with the next upload (that contains the fix), and > we'll let users report a new one if something similar still happens again > (it can't be the same violation any more due to the change in > https://github.com/cockpit-project/cockpit/pull/21332) This is fine with me. I'll continue to monitor new SELinux issues wrt cockpit on that machine.
FEDORA-2024-ba2375d278 (cockpit-330-1.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-ba2375d278
FEDORA-2024-60684a3b16 (cockpit-330-1.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-60684a3b16
FEDORA-2024-ba2375d278 has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-ba2375d278` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-ba2375d278 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-60684a3b16 (cockpit-330-1.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-f628a4fdfa has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-f628a4fdfa` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-f628a4fdfa See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-f628a4fdfa (cockpit-331-1.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.