On Mi, 24.04.19 17:28, Björn Persson (Bjorn@rombobjörn.se) wrote: > Lennart Poettering wrote: > >As mentioned before: systemd itself already needs entropy itself (it > >assigns a random 128bit id to each service invocation, dubbed the > >"invocation ID" of it, and it generates the machine ID and seeds its > >hash table hash functions) > > Given that access to entropy during early boot is so problematic, > hardware-dependent and full of catch-22s, it seems to me that an init > system should use the entropy pool only if it really must. > > With that in mind, could you explain why the invocation ID and the hash > tables need to be cryptographically secure? Why is rand or a simple > serial number not good enough? I never heard that lack of a > cryptographically secure invocation ID was a big security problem > before systemd. init systems before systemd had no notion of "sevice lifecycles", they just didn't care. systemd cares about lifecycles however, and assigns a random 128bit id (aka "uuid") to each service invocation cycle. This can be used to associate logs and resource data of a specific service invocation with each other. To be suitable for their purpose, of being *universally unique* you need a good random source for them. You cannot just use srand() and start from a fixed or time source, because then every system would always generate the same uuids... Naive hash tables are prone to collision attacks: if you know the hash function used by the hash tables you might be able to trigger a DoS by forcing collisions and thus degrading the assumed O(1) complexity of hash table operations to O(n). See bug report how this was exploitable in Perl hash tables for example: https://rt.perl.org/Public/Bug/Display.html?id=22371 Because of that modern hash table implementations (including those in systemd) will use a keyed hash function and pick a random value as seed every now and then, so that clients cannot easily trigger DoS like that. This random seed needs to be of relatively high quality, since if clients could guess the seed the excercise would be pointless. Hence no, srand() from timer or constant value wouldn't cut it. But do note that systemd doesn't use blocking getrandom() for seeding hash tables, but uses /dev/urandom instead (i.e. is happy with an uninitialized entropy pool), because for the hash table collisions it's fine if we initially don't have the best entropy as long as it gets better over time. That's because the hash tables in systemd will monitor the fill level and rehash with a fresh seed if we hit a threshold. Anyway, there are a number of other places systemd needs a bit of entropy, these are just two prominent cases. We also make use of /proc/sys/kernel/random/boot_id btw, which also needs some entropy. Lennart -- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
