SoylentNews is people
SoylentNews
Recent upgrades that depend on the new Linux getrandom() syscall can cause OpenSSH to delay starting for tens of minutes while waiting for enough bytes of randomness. There are currently not any feasible work-arounds.
Systemd makes this behaviour worse, see issue #4271, #4513 and #10621.
Basically as of now the entropy file saved as /var/lib/systemd/random-seed will not - drumroll - add entropy to the random pool when played back during boot. Actually it will. It will just not be accounted for. So Linux doesn't know. And continues blocking getrandom(). This is obviously different from SysVinit times when /var/lib/urandom/random-seed (that you still have laying around on updated systems) made sure the system carried enough entropy over reboot to continue working right after enough of the system was booted.#4167 is a re-opened discussion about systemd eating randomness early at boot (hashmaps in PID 0...). Some Debian folks participate in the recent discussion and it is worth reading if you want to learn about the mess that booting a Linux system has become.
While we're talking systemd ... #10676 also means systems will use RDRAND in the future despite Ted Ts'o's warning on RDRAND [Archive.org mirror and mirrored locally as 130905_Ted_Tso_on_RDRAND.pdf, 205kB as Google+ will be discontinued in April 2019].
Related post: OneRNG: a Fully-Open Entropy Generator (2014)
(Score: 4, Informative) by darkfeline on Friday December 21 2018, @08:19PM (19 children)
It seems systemd can do no right.
Basically, Poettering's stance is that it is not possible to know how much entropy is in the saved file, therefore systemd errs on the side of caution by not crediting the kernel's entropy counter. For example someone may ship a bad seed file and thus compromise the integrity of the kernel's CSPRNG. The counterargument is that people shouldn't be shipping bad seed files. Poettering argues that many people will do so since they may not even be aware of seed files.
If systemd defaults to less secure, people complain (see the root USER fiasco). If systemd defaults to more secure, people complain.
(Note that Poettering OKed a patch to optionally enable incrementing the entropy counter, thus solving this issue. If you enable it, it's assumed you know the security implications of shipping or not shipping a seed file.)
Join the SDF Public Access UNIX System today!
(Score: 0) by Anonymous Coward on Friday December 21 2018, @08:43PM
are equally absurd
(Score: 5, Insightful) by Thexalon on Friday December 21 2018, @09:58PM (6 children)
In your post you describe two options:
1. Secure version where SSH gets stuck for a while waiting for entropy to be collected.
2. Insecure version where SSH starts up right away but isn't guaranteed to be safe.
And then you duck right past other options, like:
3. When you load up the seed files, check to see if they're "bad" (whatever that means). If they're "bad", then generate or otherwise acquire a good seed file. Another upside of this is that you should only have to fix this once.
4. Work with distros and other relevant projects to ensure that seed files aren't "bad" as often as possible, thus making the scenario above more rare.
And this exemplifies why people don't like Lennart: He is willing to screw up user's experiences and/or other packages that rely on his stuff to "solve" a problem he either lacks the creativity or the diligence to solve. It's a consistent tendency to make changes to functioning software attempting to achieve what seems like a platonic ideal of software which has the small drawback of making it no longer work properly.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 0) by Anonymous Coward on Saturday December 22 2018, @12:20AM
you cannot distribute seed file at all. it is negative entropy when shipped. It should be generated by the system at shutdown and deleted after it is loaded at startup. if you have to bassh systemd pile on the fact that a patch was needed to have the option to enable that feature but don't blame it for a secure default.
(Score: 5, Insightful) by coolgopher on Saturday December 22 2018, @12:23AM
Ideal software? SystemD is light years further away from that now than we were with scrappy ol' SysV and individual, replaceable components. The man repeatedly fails to comprehend the core Unix tenet of "do one thing, and do it well". And I do not comprehend why people keep accepting his cruddy software into their distros. Something is rotten in the state of Linux.
(Score: 2, Troll) by darkfeline on Saturday December 22 2018, @06:15AM (3 children)
Good job exposing your own ignorance.
> When you load up the seed files, check to see if they're "bad" (whatever that means)
You can't, that's the point. There's no way to really measure entropy, you can only estimate it. If you get it from a file you have no idea what the quality is.
>then generate
The only way to "generate" entropy is to wait for it to accumulate as the kernel runs, hence the multiple minute waits after boot. You're asking systemd to do what it's already doing. Again, you're just exposing your own ignorance.
>Work with distros and other relevant projects to ensure that
Lennart is worried about people rolling their own things, like embedded. This is *especially* bad for embedded because they usually have limited entropy sources. These people (much like you) probably have very little knowledge of entropy and cryptography to get this right.
>And this exemplifies why people don't like Lennart
Because they are ignorant, don't bother to research the technical details of the problem and solution, and spout FUD? Sounds about right.
Join the SDF Public Access UNIX System today!
(Score: 3, Informative) by Thexalon on Saturday December 22 2018, @01:25PM (2 children)
Then estimate it, and see what the estimate is.
I'm asking systemd to do what it's already doing when it's actually necessary to do that, not when it is theoretically conceivable that doing that might be required.
So you're saying that folks are smart enough to roll their own, but dumb enough to get the entropy file wrong (presumably, the issue gets discussed in any books / websites / other resources they're consulting when rolling their own), and for that reason you should do something very annoying for the vast majority of users who aren't rolling their own?
Again, it's taking a theoretical issue and using it as an excuse to mess things up for everybody who isn't affected by it. Lennart has busted the kernel for similar reasons before.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2) by Pino P on Saturday December 22 2018, @08:42PM
This exposes the system to RNG attacks [wikipedia.org] in which the attacker replaces the seed file with a hand-crafted one that games the estimate.
Yes. See the "Prominent examples" in the "RNG attacks" article.
(Score: 2) by darkfeline on Wednesday December 26 2018, @01:15AM
Let me just give you a very simple example.
Take a "good" seed file. The first time this file is ever used in history, it has N bits of good entropy. Every subsequent time it is used, it has 0 bits of good entropy.
Now, tell me how systemd is supposed to estimate whether the seed file was ever used before in history? It might not even have been used on the same computer, or on the same drive, or in the same country.
This isn't a theoretical issue. Have you heard of Logjam, where everyone shipped a common Diffie-Hellman prime opening up an attack vector? Most people screw up cryptosystems, including distro maintainers and packagers.
Even IF we accept the risk, to dismiss Lennart's position off-hand is disingenuous. He has a valid point even if you disagree with it for valid reasons.
>So you're saying that folks are smart enough to roll their own, but dumb enough to get the entropy file wrong
All it takes to "roll their own" is to take an image snapshot of the disk, like for an embedded project. You don't even have to know about the seed file to get it wrong. In fact, it's the opposite: the people who don't even know about the seed file's existence are the most likely to get it wrong. If you do know about it, you're able to optionally enable it in systemd if you need it.
Join the SDF Public Access UNIX System today!
(Score: 5, Insightful) by sjames on Saturday December 22 2018, @12:28AM (8 children)
I've noticed that, but I suspect I read that in a different sense than you do :-)
If I understand, the concern is that the distributor who has already been trusted to ship an untainted system (including systemd) somehow can't be trusted to ship a good seed file? That sounds like a dumb excuse that's almost as good as "sorry, I have to wax my cow and floss the cat tonight.".
(Score: 2) by loonycyborg on Saturday December 22 2018, @07:41AM (7 children)
It's not a matter of trust. You can be absolutely sure that at least some distros will screw it up. This issue is easy to miss and won't result in bug reports from users because it doesn't break things in noticeable fashion, until it enables some attack on the system. And then it will be systemd that will be blamed for this. Damned if you do, damned if you don't.
(Score: 3, Insightful) by sjames on Saturday December 22 2018, @08:22AM (6 children)
Care to name one?
On the other hand, systemd will be rightly blamed when an embedded system appears to fail on upgrade with systemd taking over an hour in some cases to get past the random-seed issue.
In all cases like these, the rule in Unix is that the system should implement mechanism and leave policy to the admin.
(Score: 0) by Anonymous Coward on Saturday December 22 2018, @12:16PM
If you're running SystemD in an embedded system you'd probably be better off with XP.
(Score: 2) by loonycyborg on Saturday December 22 2018, @03:28PM (4 children)
Yes, it's easy to spot boot delay, research the issue and ensure there is some good source of entropy such as TPM or RDRAND. And all before the embedded system gets into user's hand.
(Score: 2) by sjames on Saturday December 22 2018, @05:57PM (2 children)
What makes you think either of those exist on an embedded device?
Some have it, some don't.
It's also easy to make it configurable and let the admin decide policy, but systemd is not very good about following the rule.
(Score: 2) by loonycyborg on Sunday December 23 2018, @09:40AM (1 child)
What do you mean? They agreed to make it configurable. The argument is only about the default value of that setting :P
(Score: 4, Informative) by sjames on Sunday December 23 2018, @06:17PM
They have agreed to nothing, that item is still open. The current discussion is more like reluctant and grudging potential agreement but let's hide that option somewhere and consider it to be experts only/debugging.
On the matter of systemd consuming the limited entropy available at boot time, they have agreed that it isn't really necessary but that they're going to keep doing it anyway.
The rest is workarounds with the kernel or the initrd taking over and doing things behind systemd's back so necessary things can get done without dealing with systemd's inability to handle it the one true systemd way.
(Score: 1) by DeVilla on Saturday December 22 2018, @08:22PM
Someone didn't read Ted's warning about RDRAND or doesn't care.
(Score: 3, Insightful) by Bot on Saturday December 22 2018, @01:09PM (1 child)
> Basically, Poettering's stance is that it is not possible to know how much entropy is in the saved file, therefore systemd errs on the side of caution
Basically, Poetterix should not take it on his shoulders to virtually sysadmin all linux boxen (boxenes, boxii, however you prefer to spell it) and make that a configurable option, so that I can access my VPS which hosts public information in less than fifteen mins.
This seems like a case of: i found a good excuse to inconvenience you, so BLAM there it is. Bonus points from my next employer, microsoft.
(note, of course my vps is systemd free)
Account abandoned.
(Score: 2) by coolgopher on Sunday December 23 2018, @01:24AM
*next* employer? His behaviour has long suggested otherwise...