[systemd-devel] /etc/machine-id has wrong SELinux file context and changes on second boot

[Dominick Grift]

It is a policy configuration issue obviously. I am not sure what version
of reference policy Yocto is using in that environment but you might want
to see if it is old. SELinux policy is very dynamic.

Frankly, according to my security policy systemd-machine-id-setup is
selinux aware like many systemd components and so it should address
labeling programmatically (if it is allowed to by the policy selinux enforces)

Can you produce this issue with selinux in permissive mode? If it works
in permissive mode but not in enforcing mode then selinux is blocking
systemd-machine-id-setup and that might cause the labeling issue.

By the way I would argue that both init_runtime_t and etc_runtime_t are
not suitable for this and that it should probably have a private
machineid_t type since AFAIK this /etc/machine-id is only ever created
by systemd-machine-id-setup.

"Sebert, Holger.ext" <Holger.Sebert.ext at karlstorz.com> writes:

> Hi!
>
> I am having issues with systemd's machine-id: On first boot it is
> created, i.e. the file /etc/machine-id changes from “unintialized” to a
> hash value; but it has the wrong SELinux file context, namely
> “init_runtime_t”.
>
> Furthermore, I am getting the following error message:
>
> localhost systemd[1]: systemd-machine-id-commit.service: Main process exited, code=exited, status=1/FAILURE
> localhost systemd-machine-id-setup[424]: Failed to unmount transient /etc/machine-id file: No such file or directory.
> localhost systemd-machine-id-setup[424]: We keep that mount until next reboot.
> localhost systemd[1]: systemd-machine-id-commit.service: Failed with result 'exit-code'.
>
> On the next boot, /etc/machine-id has the correct SELinux file context,
> namely, “etc_runtime_t”, but the ID has changed! On subsequent boots,
> it remains unchanged, however.
>
> I think this could be related to this old bug:
>
> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1411140
>
> And, indeed, we are also using OverlayFS (in a Yocto/Poky (mickledore)
> environment).
>
> Do you have an idea how to work around this problem?
>
> Best,
> Holger

-- 
gpg --locate-keys dominick.grift at defensec.nl (wkd)
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift
Mastodon: @kcinimod at defensec.nl