Description of problem: This few days whenever I startup my pc, before anything, a popup from seepleat will inform me there is an error. Have been ignoring for few days but wonder if reporting would help. 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-37.14-1.fc37.noarch Local Policy RPM cockpit-ws-279-1.fc37.x86_64 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 6.0.8-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Nov 11 15:09:04 UTC 2022 x86_64 x86_64 Alert Count 2 First Seen 2022-11-16 07:43:53 +08 Last Seen 2022-11-16 07:43:53 +08 Local ID d1e0b466-dc6e-4325-a2e6-c07a72ad5ce2 Raw Audit Messages type=AVC msg=audit(1668555833.572:230): avc: denied { search } for pid=1236 comm="hostname" name="net" dev="proc" ino=1427 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-37.14-1.fc37.noarch Additional info: component: cockpit reporter: libreport-2.17.4 hashmarkername: setroubleshoot kernel: 6.0.8-300.fc37.x86_64 type: libreport
*** Bug 2143403 has been marked as a duplicate of this bug. ***
Thanks for reporting! 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. - /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. However, I'm still unable to reproduce this, and it does not turn up in our integration tests either. I tried restarting cockpit-motd.service, `hostnamectl set-hostname --static foo` (as in the duplicate), rebooting, etc. Adding `set -x` to /usr/share/cockpit/motd/update-motd just confirms that this does call hostname, and adding `ls -lZ /proc/self/stat` confirms that this runs as cockpit_ws_t. Can you please show me the output of semodule --list-modules=full|grep cockpit ?
I updated my Fedora 37 VM to the latest packages (sorry, it was already 7 days old), this upgraded selinux-policy from 37.12-2 to 37.14-1.fc37. This has a major change, it drops its own (obsolete) cockpit policy, and only leaves it up to cockpit. So with the old version it was supposed to look like this: # semodule --list-modules=full|grep cockpit 200 cockpit pp 100 cockpit pp Now the selinux-policy module is gone, and it should look like this: # semodule --list-modules=full|grep cockpit 200 cockpit pp However, I still don't get the AVC with a fully updated F37. It seems like a recent upgrade of selinux-policy/cockpit did *something* different on your systems. cockpit's SELinux policy has the necessary permissions: https://github.com/cockpit-project/cockpit/blob/main/selinux/cockpit.te#L40 https://github.com/cockpit-project/cockpit/blob/main/selinux/cockpit.te#L83 but apparently it's not correctly applied on your system. Did you actually enable cockpit? I.e. `systemctl is-active cockpit.socket` Does cockpit itself work for you, i.e. can you log in on http://localhost:9090 ?
OK,I'll jump in here. I do get this: Before updates: # semodule --list-modules=full|grep cockpit 200 cockpit pp 100 cockpit pp And after the updates: # semodule --list-modules=full|grep cockpit 200 cockpit pp Cockpit is fully operational, I use it all the time. Along with the Selinux issue I reported in bug 2143403 I am also seeing this in my Logs "pam_listfile(cockpit:auth): Couldn't open /etc/cockpit/disallowed-users" and the following log entry says "pam_ssh_add: Identity added" which is fine I think. I mention this as I am not sure if this is related at all.
FYI I have not seen Selinux issue I reported in bug 2143403 and I have no idea what could of changed to affect this. Of course I will keep an eye on it.
Thank you everyone for your valuable feedback. Since I have not started using cockpit yet since the installation, I guess I'll just go ahead and uninstall it then. Thanks again. *Do I have to close this ticket or the admin will determine?
Arashi: Colin reported that his instance of the problem is gone. We still expect no SELinux violations even if you have cockpit installed. But it would help me a lot if you could give me the output of systemctl status cockpit.socket cockpit cockpit-motd and check if you still get the AVC (after a reboot, if you can -- that'd be helpful) In particular, if cockpit never started (as it's disabled), but you still get that AVC, then this would reduce the places that this could come from. Thanks!
(In reply to Martin Pitt from comment #7) > Arashi: Colin reported that his instance of the problem is gone. Almost Martin, I shut down every evening but sometimes I get the AVC on restart, like this morning. I then shutdown (was @work) restarted tonight and no AVC... puzzling. I think something else is amiss, will try and investigate time permitting.
Update.. I cannot reliably reproduce this sorry. I can go a up to a week with no alerts, then all of the sudden I may get a couple randomly. Every time the report seems the same. I'll keep looking to try and find a cause. Perhaps some update triggers it.
Update #2 I do not see this error at all now so I guess it can be closed? As mentioned in bug 2143403 this started with me when I changed my hostname and then became very sporadic when it occurred. I just could not reliably reproduce it. Over the holiday I found an error (missing entries) in my hosts file and since fixing that I have seen no errors. Related to this I am not sure..
I got this on my system as well: Contesto della sorgente system_u:system_r:cockpit_ws_t:s0 Contesto target system_u:object_r:sysctl_net_t:s0 Oggetti target net [ dir ] Sorgente hostname Percorso della sorgente hostname Porta <Sconosciuto> Host (removed) Sorgente Pacchetti RPM Pacchetti RPM target SELinux Policy RPM selinux-policy-targeted-37.19-1.fc37.noarch Local Policy RPM cockpit-ws-284-1.fc37.x86_64 Selinux abilitato True Tipo di politica targeted Modalità Enforcing Enforcing Host Name (removed) Piattaforma Linux sbonazzo.remote.fedora 6.1.12-200.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Feb 15 04:35:34 UTC 2023 x86_64 x86_64 Conteggio avvisi 2 Primo visto 2023-02-23 08:41:45 CET Ultimo visto 2023-02-23 08:41:45 CET ID locale c9727ee8-e18e-42ce-a89b-9313671b4241 Messaggi Raw Audit type=AVC msg=audit(1677138105.621:340): avc: denied { search } for pid=2438 comm="hostname" name="net" dev="proc" ino=19944 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
*** Bug 2144606 has been marked as a duplicate of this bug. ***