[Server-devel] quasi-automatic security updates: state-of-art headed where?

[James Cameron]

On Mon, Aug 15, 2016 at 09:56:43AM -0400, Adam Holt wrote:
> "yum update" on CentOS regularly tells me that "yum-cron" should
> likely be installed+run instead.  Does anyone have experience /
> informal recommendations (or just tricks-of-the-trade, no matter how
> hacky) around yum-cron or dnf-automatic or similar, in Debian-land
> or all around?  Ideally some such/ similar would:
> 
> (1) be patient enough to deal with developing world servers being
> offline for many months at a time, yet smart enough to grab security
> updates quickly when Internet appears unpredictably every few weeks
> or months (or years, such server are almost inherently
> re/distributed re/donated re/sold Without centralized
> control...Internet-of-Things / IoT "anarchy" fears are indeed
> relevant+real ;)

Already implemented; a scriptlet is run by Network Manager when the
connection appears, and begins download of updates.

Downside is that the connection may have been made for a reason other
than downloading updates, and it can be quite irritating to the site
user to share their bandwidth with the updates.

As bandwidth increases for the 1% more such upstream policy decisions
are taken.  Removing agency from the owner.

> (2) Ideally only download "security" updates (however informally
> managed, anything closer to LTS than constant upgrades of
> major/minor packages!)  Is CentOS catching up to RHE on this front,
> or does Red Hat intentionally differentiate its products such that
> Red Hat Enterprise gets security updates faster or in a cleaner way?

Having been a Red Hat Enterprise support engineer; yes, Red Hat
customers do get security updates faster than CentOS does (of cour$e),
but the delay will vary.  From point of view of a CentOS user, worst
delay is where a Red Hat customer has asked for the issue to be fixed
and been given an early fix, and best delay is for a well known and
announced update.

> (3) Avoid bloating smaller (e.g. 120GB) SSD drives & 128GB MicroSD
> cards driving RPi3's and similar?  Sometimes I see ~100MB/week of
> updates from "yum update" which makes me wonder if yum is smart
> enough to fully delete not just deprecate older/unused packages?? 
> Hopefully I am wrong to fear disk bloat.  Or does this truly
> represent an estimated ~5GB/year of disk bloat in recent years,
> purely for OS-level updates?  (Part of a larger challenge on how to
> manage bloat of log files, content files, tmp files, user files for
> sure!)

Already implemented; old version of files are deleted when update is
applied, and downloads are deleted afterwards.  If you have disk
bloat, it will be some other cause.

> (4) Email the owner of the machine (offline is increasingly online,
> no matter how we slice it: offline servers will increasingly be at
> risk for years to come sad to say!)  Some kind of interface to Gmail
> or a similar online notification service should be possible when the
> server reappears online, without running a mail server heaven
> forbid?  For moments when truly-more-critical-intervention's
> required -- with the obvious risk that excessive "nagware" and
> "liabilityware" warnings will be ignored or far worse -- when local
> (often less-literate) operators even exist at all within developing
> world schools, trying their best!

Already implemented; several things provide this kind of service, and
a mail server is not required on the system.

> PS there's no perfect solution for sure -- Apple/Microsoft/Google
> spend many, many millions on their security-auto-updating infra
> (nevermind associated UX's) we just don't have.  Offline security
> updates on a quasi-monthly basis may be one answer, if older
> quasi-offline solutions from the 1990s also/still have legit hope &
> lessons for us all?  What should such services cost, if it comes
> down to money?

As much as the market will pay.  Which can be from zero to lots.

> As real-world challenges evolve: what practical non-puritanical
> compromises are evolving out there in CentOS-land / Debian-land /
> Etc as "offline increasingly becomes online" ?  (as serious online
> risks increasingly reach offline servers, IoT devices, etc...what
> quasi-automatic security update regimes should we be looking at for
> the coming decade, realistically?)  Thanks for ideas facing up to
> these existential challenges uniting us all, knowing there's a
> serious diversity of opinions / tripwires / threat models /
> mitigations out there quite naturally!

Go for a shorter planning horizon than a decade.

-- 
James Cameron
http://quozl.netrek.org/