/var/run/keylime is deleted when system is rebooted

[kkaarreell]

Is your an issue a feature request? If so, please raise it as an enhancement

Environment

• OS / version: Fedora, RHEL
• Processor architecture:
• TPM Manufacturer:
• Keylime version: latest upstream e12658b

Description

/var/run/keylime is removed with reboot since systemd manages /var/run content. This leads to

keylime.cloudverifier - INFO - Starting service for revocation notifications on port 8992
Process zeroMQ:
2022-06-10 14:10:32.143 - keylime.cloudverifier - INFO - Starting server of process 0
Traceback (most recent call last):
  File "/usr/lib64/python3.9/multiprocessing/process.py", line 315, in _bootstrap
    self.run()
  File "/usr/lib64/python3.9/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.9/site-packages/keylime-6.4.1-py3.9.egg/keylime/revocation_notifier.py", line 38, in worker
    os.makedirs(dir_name, 0o700)
  File "/usr/lib64/python3.9/os.py", line 225, in makedirs
    mkdir(name, mode)
PermissionError: [Errno 13] Permission denied: '/var/run/keylime'

Is /var/run/keylime used only by the revocation notifier which is started by the verifier or is it used also by the one that is started by keylime agent? If it is only verifier who is using it then it would be probably enough to define it the verifier unit file.

[service]
RuntimeDirectory=keylime
RuntimeDirectoryMode=700

However if the usage is more complex then we should probably use tpmfiles.d configuration since when using the approach above /var/run/keylime is removed when verifier is stopped.

I have configured tpmfiles.d like this:

echo 'd /var/run/keylime 0700 keylime keylime' > /usr/lib/tmpfiles.d/keylime.conf

Expected behavior vs. actual behavior

No traceback. /var/run/keylime is managed by systemd.

Steps to reproduce problem

1. Install keylime
2. Reboot
3. Run attestation scenario

[kkaarreell]

Hi @sergio-correia , I think you have already applied a fix for this one, didn't you?

[sergio-correia]

Not yet, it's waiting for the next update, which should happen... soon(tm). I was waiting for a new release to be tagged with the recent fixes, but if one will not happen very soon, I will go ahead and update it with this fix anyway.

@mpeters: do we expect a new release soon?

[mpeters]

yes, I'm going through the current outstanding PRs to see if they are ready or close to it. Expect a new version soon.

[kkaarreell]

@sergio-correia Any update?

[sergio-correia]

This was fixed in Fedora with release 6.4.2. Are you still experiencing the issue?

[kkaarreell]

We have a workaround in place so we are not experiencing it. I was thinking about removing it but then saw this issue still being open. Has this been addressed in upstream keylime install script?

[kkaarreell]

It seems this issue is still not fixed upstream. In Fedora this is addressed with
https://src.fedoraproject.org/fork/ksrot/rpms/keylime/blob/rawhide/f/keylime.spec#_248
@THS-on Any preference about the upstream fix?

[THS-on]

The systemd way is probably the most distribution agnostic way to fix this.

Can you make a PR for that that creates that file if you install the systemd services?

[kkaarreell]

The systemd way is probably the most distribution agnostic way to fix this.
Can you tell which services are using this directory?

[kkaarreell]

It seems that sharing one directory by multiple services is not good idea
systemd/systemd#5394

[THS-on]

The verifier and the IMA emulator service use it, so we can move the IMA emulator service to another dir and only use /var/run/keylime for the verifier.

[kkaarreell]

So we would also need a new service file for IMA emulator.

[THS-on]

Maybe, it currently runs as root and can just create its path.

[THS-on]

We are going to remove the IMA emulator with 7.0.0, so then we definitely only need it for the server components.