Bug#941300: finish-install: write random seed to correct location for chosen init system
On Wed, 2019-10-02 at 17:59 +0800, Ian Campbell wrote: > If it's going to override/shadow (as opposed to simply working > alongside/in parallel) urandom, probably it ought to also be looking > at/consuming the urandom seed? Perhaps. I'm not sure systemd upstream would be convinced though. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#941300: finish-install: write random seed to correct location for chosen init system
On Wed, 2019-10-02 at 08:59 +0800, Paul Wise wrote: > On Tue, 2019-10-01 at 11:55 +0100, Steve McIntyre wrote: > > > Wouldn't it just be easier to write it one location and replace the > > other with a symlink to it? > > Looks like neither the urandom init script nor systemd-random-seed > unlink the file before writing to it, so this could potentially work > unless that changes at some point. Just writing two different seeds > avoids the need to care about what the implementations will do in the > future so I think it is safer. The original report says: > systemd-random-seed.service overrides the urandom init script > but uses a different location for its random seed file If it's going to override/shadow (as opposed to simply working alongside/in parallel) urandom, probably it ought to also be looking at/consuming the urandom seed? Ian.
Bug#941300: finish-install: write random seed to correct location for chosen init system
On Tue, 2019-10-01 at 11:55 +0100, Steve McIntyre wrote: > Wouldn't it just be easier to write it one location and replace the > other with a symlink to it? Looks like neither the urandom init script nor systemd-random-seed unlink the file before writing to it, so this could potentially work unless that changes at some point. Just writing two different seeds avoids the need to care about what the implementations will do in the future so I think it is safer. Looking at systemd's documentation, on non-virtual systems d-i should probably also write to the random seed stored in the UEFI ESP, in case the user decides to use systemd-boot instead of initramfs-tools. https://systemd.io/RANDOM_SEEDS.html -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#941300: finish-install: write random seed to correct location for chosen init system
On Sat, Sep 28, 2019 at 05:20:47PM +0800, Paul Wise wrote: >Package: finish-install >Version: 2.56 >Severity: important >Tags: security >Control: found -1 2.81 >Control: found -1 2.100 >Control: found -1 2.101 > >finish-install creates a random seed in the location used by the >urandom init script from the initscripts package. On systemd based >systems, systemd-random-seed.service overrides the urandom init script >but uses a different location for its random seed file. Consequently on >first boot of systemd based systems there is no random seed file so the >amount of entropy available is lower. > >/var/lib/urandom/random-seed >/var/lib/systemd/random-seed > >I think finish-install needs to fix this with one of these options: > > 1. Write the random seed to both locations. This means that when > switching init systems you get the old random seed. > 2. Write two different random seeds to the two locations. This means > that when switching init systems you get the a new random seed that > has never been used before, but which was generated during the > install. > 3. Detect the chosen init system and write the random seed to the > location preferred by that init system. This means that when > switching init systems the first boot of the new init systems has no > random seed. > >I think probably the second scenario is the best since then there is >always a random seed available even when switching init systems and >that random seed is never reused. Wouldn't it just be easier to write it one location and replace the other with a symlink to it? -- Steve McIntyre, Cambridge, UK.st...@einval.com < sladen> I actually stayed in a hotel and arrived to find a post-it note stuck to the mini-bar saying "Paul: This fridge and fittings are the correct way around and do not need altering"
Bug#941300: finish-install: write random seed to correct location for chosen init system
On Sat, 2019-09-28 at 17:20 +0800, Paul Wise wrote: > Package: finish-install > Version: 2.56 > Severity: important > Tags: security > Control: found -1 2.81 > Control: found -1 2.100 > Control: found -1 2.101 > > finish-install creates a random seed in the location used by the > urandom init script from the initscripts package. On systemd based > systems, systemd-random-seed.service overrides the urandom init script > but uses a different location for its random seed file. Consequently on > first boot of systemd based systems there is no random seed file so the > amount of entropy available is lower. [...] This should improve the randomness of /dev/urandom. However, the last time I checked, the systemd service does not change the kernel's entropy accounting. (And there was a small risk of using the seed twice, which would need to be fixed before changing that.) So this does not help with the problem of slow boots due to the kernel not accounting enough entropy. Ben. -- Ben Hutchings Sturgeon's Law: Ninety percent of everything is crap. signature.asc Description: This is a digitally signed message part
Bug#941300: finish-install: write random seed to correct location for chosen init system
Package: finish-install Version: 2.56 Severity: important Tags: security Control: found -1 2.81 Control: found -1 2.100 Control: found -1 2.101 finish-install creates a random seed in the location used by the urandom init script from the initscripts package. On systemd based systems, systemd-random-seed.service overrides the urandom init script but uses a different location for its random seed file. Consequently on first boot of systemd based systems there is no random seed file so the amount of entropy available is lower. /var/lib/urandom/random-seed /var/lib/systemd/random-seed I think finish-install needs to fix this with one of these options: 1. Write the random seed to both locations. This means that when switching init systems you get the old random seed. 2. Write two different random seeds to the two locations. This means that when switching init systems you get the a new random seed that has never been used before, but which was generated during the install. 3. Detect the chosen init system and write the random seed to the location preferred by that init system. This means that when switching init systems the first boot of the new init systems has no random seed. I think probably the second scenario is the best since then there is always a random seed available even when switching init systems and that random seed is never reused. I think this issue should get fixed in stable/oldstable too. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
