audit2allow policy

Context is init_var_run_t while systemd-hostname wants systemd_hostnamed_t.

Policy expected:

module systemd-hostnamed 1.0;

require {
        type init_var_run_t;
        type systemd_hostnamed_t;
        class sock_file create;
}

#============= systemd_hostnamed_t ==============
allow systemd_hostnamed_t init_var_run_t:sock_file create;

Next steps

If we would be in another distribution family, to load a custom policy as above would make sense.

But on CentOS Stream, it should be supported out of the box.

Both systemd and selinux can be updated on CentOS Stream, so let's start with a package update, and if still present, we'll report upstream.

Still an error with last packages versions.

Normal behavior observed with the policy:

Sep 10 21:10:02 dwellers.nasqueron.org systemd[1]: Starting systemd-hostnamed.service - Hostname Service...
Sep 10 21:10:02 dwellers.nasqueron.org systemd[1]: Started systemd-hostnamed.service - Hostname Service.
Sep 10 21:10:02 dwellers.nasqueron.org audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Sep 10 21:10:02 dwellers.nasqueron.org systemd[2235]: Started snap.starship.starship-2c433cb5-3ffe-4c28-a736-624772356a4f.scope.

Was looking to offer a fix upstream, like read hostname from /proc/sys/kernel/hostname on Linux, but then I've realised this is an interaction issue with snap, starship, systemd and SELinux.

The issue can only occur when gethostname() is called on specific cases like D-Bus or here Varlink.

21:24:56 < Dereckson> Tiens je viens de m'apercevoir qu'un bug d'intercation entre SElinux, starship et systemd c'est une histoire drôle en fait
21:25:00 < Dereckson> "SELinux, systemd and a full Rust piece of software to set a prompt are in a boat..."
21:26:21 < Dereckson> Chaque nouveau shell (donc chaque division d'un panneau dans tmux) lance starship, qui appelle gethostname() ; jusque là, pourquoi pas ?
21:26:46 < Dereckson> Sauf que starship est installé via snap.
21:28:01 < Dereckson> Donc du coup gethostname() appelle systemd-hostnamed qui doit créer un socket (où d'ailleurs ? l'audit de SELinux ne me l'a pas documenté, pas sûr que ce soit dans /run/systemd)
21:28:36 < Dereckson> Déjà là, ça devient intéressant de savoir que sur un Linux "moderne", il faut lancer un serveur pour récupérer le hostname
21:29:34 < Dereckson> bref, systemd-hostnamed a besoin de créer son socket, et SELinux bloque car il est dans du init_var_run_t, et pas du systemd_var_run_t
21:29:46 < Dereckson> Le fix est trivial : allow systemd_hostnamed_t init_var_run_t:sock_file create;
21:30:16 < Dereckson> Mais ce qui me sidère dans l'histoire c'est le coup du prompt qui appelle un logiciel Rust complet qui lance un service de systemd pour récupérer le hostname
21:31:05 < Dereckson> on se demande pourquoi ça prend quelques centaines de ms de lancer un shell sur ectte machine après
[...]
21:49:32 < Dereckson> à noter que gethostname N'invoque PAS systemd-hostnamed en dehors de cas spéciaux comme dbus ou ici Varlink
21:50:04 < Dereckson> donc fallait vraiment le faire exprès : snap, starhip, systemd, SELinux
21:53:19 < Dereckson> (la solution la plus simple serait de packager starship sur EPEL)
21:53:45 < Dereckson> (au lieu de jouer avec snap)

Going to submit a policy fix to fix that issue now, then we'll get rid of this hell scenario with T2122.