smuellerDD/jitterentropy-rngd

Regression: systemd unit hardening renders jitterentropy service useless

silentcreek opened this issue · 5 comments

silentcreek commented

Hi,

I'm running jitterentropy-rngd 1.0.8 on Debian Buster. When I saw commit cc8c38c "Harden systemd service", I thought, cool, additional hardening is always nice, so I tried to apply the changes from that commit to my jitterentropy service. But after doing so, I noticed that the available entropy was reduced significantly, roughly by a factor of 10. I then started to bisect the additions to see which hardening option causes this. It turns out that two options cause this issue:
CapabilityBoundingSet=
and
PrivateUsers=yes

If I remove these two lines, then the available entropy looks fine again.

Now, how did I test this:
The hardware I use is a small ARMv7 single board computer without a hardware RNG. The available entropy after boot is quite low (<100) without jitterentropy-rngd. Adding the jitterentropy service increases the available entropy signigicantly to roughly 1000. For my testing I added a small cronjob to log the available entropy after boot to a file, so I could compare it and see how the various systemd unit options impact it. That was by no means a scientific test, but given the significant differences, I think it was ok. The cronjob looked like this:
@reboot cat /proc/sys/kernel/random/entropy_avail > /tmp/entropy.log && sleep 60 && cat /proc/sys/kernel/random/entropy_avail >> /tmp/entropy.log

Without any hardening applied, the first value is between 900-1000, and the next reading is between 1100-1200. With PrivateUsers=yes, the values for both readings are below 100. With CapabilityBoundingSet= it's mostly the same, but in one run I got values of 200-300. But still, that's much lower than without hardening. So something goes wrong with these...

Regards,

Timo

silentcreek commented

Quick update: I cannot reproduce this on amd64! But, I can on another ARMv7 board (running Debian Buster armhf). This is odd...

smuellerDD commented

Thanks a lot for the report. You are right, this is too much of a lockdown. Use the following modified options. I will push a patch shortly:

CapabilityBoundingSet=CAP_SYS_ADMIN
PrivateUsers=no

The reason is that we need CAP_SYS_ADMIN for the IOCTL.

silentcreek commented

Thanks, I was about to update this issue as well today, because I finally did reproduce the issue on amd64 as well. The reason I couldn't first, was that I messed up the unit file in a way that lead to all hardening options to be ignored. With that typo fixed, I can reproduce the issue. And, more importantly, I also tested your suggested changes and can confirm this fixes the issue! Thanks.

Final nitpick: I suppose PrivateUsers=no is a bit superfluous since it's the default value anyway. But it doesn't hurt either.

smuellerDD commented
smuellerDD commented

Fixed with the latest update. Thanks.