Bug 2143070

*** 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. ***