[Pkg-utopia-maintainers] Bug#805449: Amplification

[Simon McVittie]

On Sun, 27 Aug 2017 at 10:45:30 +0100, Barak A. Pearlmutter wrote:
> If I might ask, how is this currently handled with
> unattended-upgrades? [...] Just leaving the system vulnerable
> until a coincidental reboot doesn't seem appropriate.

It is (or should be) handled the same way as upgrading the kernel, which
cannot be replaced in-place; display managers like gdm, which cannot
be replaced in-place without disrupting user sessions; and in general
anything that isn't conveniently restartable by a systemd unit or
init script, like user sessions and user-provided code.

dbus.postinst touches /var/run/reboot-required, which is apparently
used by unattended-upgrades to detect that a reboot is needed
(/etc/kernel/postinst.d/unattended-upgrades does the same thing).
If there are other APIs for notifying the rest of the system that a
reboot is needed, I'd be happy to add them - please file a wishlist bug
with a link to their API documentation. #867263 suggests that there
might be some other API that provides more information than "a reboot
is needed", but doesn't specify who consumes that information or what
its "API" is, so is not currently actionable.

In general, unattended upgrade infrastructure can't know for sure that
a reboot isn't needed. If there's a bad enough security vulnerability
to be seriously concerned about it, the safe thing to do is to reboot
the system, to ensure that there can't be any lurking libraries or
configurations from before the upgrade. I know this is disruptive,
particularly on systems that have been designed with the assumption
that reboots don't often happen, but it's also the only way to be
sure; and system designs have to be able to cope with semi-frequent
reboots *anyway*, because the kernel semi-frequently has exploitable
vulnerabilities fixed.

This is one of the main reasons that non-apt OS deployment mechanisms
like OSTree require a reboot to apply an upgrade. The other is that
their designers want to perform an atomic cut-over from one
good/consistent state to another, eliminating the transitional
undefined/broken state that occurs during apt/rpm/etc. upgrades, which
could cause incorrect behaviour when related code runs during the upgrade
or if the upgrade is interrupted by a power failure, an unexpected reboot
or sysadmin action.

    smcv