A recent thread on the desktop-architects mailing list touched on a subject
that tends to generate strong feelings: automatic, silent updates for
security issues. At first blush, it is an attractive idea that might help
slow down or stop a fast-moving virus or other malware. It also would help
protect users who might otherwise ignore or delay updating their system.
On the other hand, there are lots of concerns about whose decision it is to
have a "mandatory" update, what else might be contained in such an update,
as well as how to ensure that the update doesn't break the user's machine.
Dan Kegel kicks off the discussion by
Given how much malware is out there,
shouldn't security fixes for remotely exploitable
flaws be installed a bit more forcefully?
e.g. instead of an ignorable notification,
how about an in-your-face dialog saying
they're going to be installed now?
Or in some cases even just silently installing them?
This goes not just for distros; any ISVs is on
the hook for rapid security updates these days,
I would think.
While there are attractions, one of the immediate downsides was noted by KDE hacker Aaron Seigo: "distro Q/A resources would have to _significantly_ increase for this to work
reliably. too many updates still break too many systems on too regular a
basis." The first time a silently applied "fix" breaks someone's
system, there will be a serious outcry. Microsoft and others have broken
people's systems before with security updates, but that doesn't seem a good
example to follow.
But, even with additional QA, there are plenty of reasons that a user might
not want to get an update. GNOME foundation member Dave Neary presents several scenarios:
I for one would be a little paranoid about not being able to control
installs of updates. I can imagine all kinds of scenarios where it would
be undesirable: a 20M security fix starts downloading when I'm connected
via GPRS at a conference, or over a 56K phone line; a kernel update
downloads & requires a reboot; an application I am using and Absolutely
Positively Must Keep Using for a few minutes upgrades, and isn't
runtime-compatible with the update [...]
A kernel reboot or even application restart are definitely problem areas.
There are many reasons a user might need to continue using a buggy
application or kernel, even if the bug exposes them to an exploit. Some
users have enough information to make that kind of determination, but
others most definitely do not. How does the distribution or software
package determine that? Presumably there will have to be settings to
govern the behavior, which then begs the question: what is the default
An additional problem is that users are training themselves—or the
desktops and distributions are training them—to ignore pop-ups of various
sorts. So suggestions like the one made by
Ritesh Raj Sarraf: "For updates with priority 'security', I think it
should just pop-up more
often" are met with skepticism. Kegel opines:
People ignore dialogs like that. IMHO if we're going to avoid
botnet nightmares, we're going to need at least some silent security
That provoked a rather boisterous response
from Linus Torvalds. His argument is that you can't trust the developers
of various projects to determine what fixes should be applied. He is
concerned that projects might want to slip
other things into a "security" release:
Yes, they may "technically" be the people with the most information, but
they are also the ones furthest removed from actual users - by definition.
And they are also the ones that are most emotionally (and often
financially) tied to things like "newest version".
His point is that he, and by extension other sophisticated users, are never
going to turn over their systems to the whims of outsiders. He is
willing to let distributions or even some
software packages make that kind
of decision, but only if things
are not done silently. "There
are programs that I trust to do their auto-updates, and I'm perfectly
happy having firefox check for extensions automatically, for example. But
even in the case of firefox, I want to _know_ when it does so."
Any kind of automated, silent upgrade feature from either a particular
package or a distribution would be an enormous target for those with a
malicious intent. It would be a kind of dream exploit to be able
to inject malware into millions of unsuspecting systems—silent and
unnoticed. A break-in to a distribution server might lead to an incredible
malware outbreak, though the same thing could be accomplished today; it
would just take more time.
But, the problem remains that there are lots of systems that are not
getting updated and are thus vulnerable to a wide variety of exploits. As
part of its Collaboration Summit, the Linux Foundation would like to have a
meeting to discuss the issue. It is
certainly an area where more thought is needed.
to post comments)