[CentOS] why not have yum-updatesd running by default?

[Bennett Haselton]

On Wed, Dec 28, 2011 at 11:33 AM, Jim Wildman <jim at rossberry.com> wrote:

> The 'E' in CentOS stands for Enterprise.  Enterprises use change
> control.  Servers do not update themselves whenever they see an update.
> Updates are tested (not so much), approved and scheduled, hopefully in
> line with a maintenance window.  In most enterprises that I've been in,
> a server can't even contact the default repo servers.  And remember that
> for a RHEL server, it has to be registered with RHN before it can
> officially receive updates.  Defaulting yum-updatesd to on will be a no-op
> in almost every 'enterprise' case.
>
> Enterprises also don't hang servers directly off the Internet.  There
> are many layers betwixt the wild web and the OS.
>
> In the decade plus that I've been running RHEL, I've seen 1 update that
> was worthy of an emergency change to push it out RIGHT NOW to the
> servers.  And even that one didn't really need to be done.
>
> ----------------------------------------------------------------------
> Jim Wildman, CISSP, RHCE       jim at rossberry.com http://www.rossberry.net
> "Society in every state is a blessing, but Government, even in its best
> state, is a necessary evil; in its worst state, an intolerable one."
> Thomas Paine
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
>

To be more clear, I wasn't saying that for the particular people on this
list, of whom many are professional sysadmins, that it would be the best
option.

I'm talking about the majority of users who have leased a dedicated server
or a VPS for $5-$50 per month, and cannot ever be realistically expected to
change much of the defaults.  In that situation, you're weighing the
likelihood, and the undesirability, of two outcomes: either (1) the machine
ends up going down temporarily because of a bad update, or (2) the machine
ends up being hacked and attacking other networks because it wasn't
receiving updates.

(Side note: my friend replied to clarify that the "kernel exploit" he was
talking about that was found in March of this year, was one that allowed a
local user to gain root privilege, not one that allowed a remote user to
get in through the webserver or sshd.  So let's say it really is true
that running automatic "yum" updates is not the most important thing to
keep out remote users, and that the majority of webserver hacks do occur
through out-of-date web apps.  Then replace everything I said with "update
the web apps" instead of installing the "yum update" patches.)

Would it not be best for the vast majority of those users to have updates
turned on by default?  If not, why not?  (Power users can always turn them
off, after all.)

Look, one may think that root access to dedicated servers (and
virtual/dedicated servers, which are almost as powerful/dangerous) should
never be given out to people who haven't been professionally trained.
(Some people still say that about net-connected computers generally!)  But
that can never be rolled back now, as long as hosting companies can legally
sell unmanaged dedicated/VPS machines to the public, they will.  So what
can be done to reduce the risks?

Or look at it this way: Suppose the government or some foundation offered a
$1 million prize for any proposal that permanently lowered the rate at
which CentOS servers were compromised.  If you actually come up with a
solution that lowers the rate, you get the money, but if you say that all
end users "should" do such-and-such (and they don't), then you get
nothing.  What would your proposal be?

My suggestion would be:
1) Implement an API call on the OS for "send this message to the machine
owner".  When the OS is installed on the machine, the person installing it
decides how the "notify" call would be implemented -- send an email to an
address, send a SMS message, whatever.  If a hosting company sets it up,
they could implement the call so that it automatically opens a new support
ticket waiting for the customer's attention.
The reason for #1 is that if the OS wants to notify the machine admin that
there's a problem, then -- at least in the case of a remotely hosted cheap
server or VPS -- you can't rely on the admin logging in and seeing the
message.  You have to proactively grab their attention somehow.  Then you
could use this function call for lots of things, but most importantly for
#2:
2) Implement some sort of scanner program (enabled by default) that would
regularly scan the machine, not just for known viruses, but for *anything*
that was known to be a frequent vector for attacks, that was not configured
to update itself automatically.  And:
- If the scanner finds an app that is not configured to update itself
automatically, it sends a low-priority message (using #1) saying "There are
no known exploits for this thing right now, but you really ought to turn on
updates for it."
- If the scanner finds a web app like WordPress that *cannot* update itself
automatically, say "This app can't auto-update itself, so you're taking a
certain risk just by having it at all.  Just sayin'."
- If the scanner finds an out-of-date component for which there is a known
exploit, send a high-priority message saying "This component needs to be
updated or you will be hacked."  (If the hosting company implements this by
opening a support ticket, they can also see if the customer doesn't respond
to the ticket, and threaten to disconnect them if they don't handle it.)

What would your proposal be?  (Remembering that you can't change human
nature, so if it relies on the majority of end users devoting time that you
think they "should" do, it won't happen :) )

Bennett