Applying Unstable --> Testing logic to Debian security updates

Posted by Nickj on Sat 12 Feb 2005 at 05:55

I'm looking for a way to automatically install security updates on a webserver running Debian stable, but with a twist: that the installation should be delayed a few days from when the updated package is released.

My reasoning for wanting this is based on these fairly straight-forward assumptions:

The Internet is an extremely hostile network.
New security flaws are always going to be found.
Initial security fixes may (despite the best efforts of the Debian Developers) be found to be buggy, introduce new vulnerabilities, or not fix the problem completely.
Finding and fixing these problems in updated packages takes time.
Updates can be revised multiple times.
I may not always be available to hand-install updates - I may get sick, be on holidays, the office's network might be down, etc.
Anything that makes administration more automated, and less prone to human error, is generally a good thing.

What I have currently is automatic downloading and notification of updated packages, via a simple cron job that calls apt. I can easily add something to this to install packages as soon as they are downloaded, but based on the above reasons I'm not comfortable doing that. What I do currently is hand-install updates after a suitable delay, but this leaves the machine vulnerable if I'm not available to do this, plus the criteria I'm following are quite strict and straightforward, so it feels like an administrative task that could be automated.

My basic idea of how this could work is something like how packages migrate from unstable to testing (i.e. a package must go for 10 days without changes before it makes the transition, and all of its dependencies must be satisfied). Basically I want something that applies the same logic as that, to downloaded security updates for Debian.

So using 2003's OpenSSH updates as an example, with a 10 day delay, the hypothetical timeline would be like so:

Prior to 17-Sept-2003, previous version of SSH installed
On 17-Sept-2003, SSH updates released (DSA-382-1)
Later on during 17-Sept-2003, revised SSH updates released (DSA-382-2)
18-Sept-2003 as part of cron.daily: Updated DSA-382-2 packages automatically downloaded
18-Sept-2003 as part of cron.daily: Delayed installer does not install SSH updates as only 0 days old
19-Sept-2003 as part of cron.daily: Delayed installer does not install SSH updates as only 1 day old
20-Sept-2003 as part of cron.daily: Delayed installer does not install SSH updates as only 2 days old
21-Sept-2003 as part of cron.daily: Delayed installer does not install SSH updates as only 3 days old
On 22-Sept-2003, revised SSH updates released (DSA-382-3)
22-Sept-2003 as part of cron.daily: Updated DSA-382-3 packages automatically downloaded
22-Sept-2003 as part of cron.daily: Delayed installer does not install SSH updates as only 0 days old (note: restarts the counter on the age of the updates)
23-Sept-2003 as part of cron.daily: Delayed installer does not install SSH updates as only 1 day old
.. skip forward a bit ...
1-Oct-2003 as part of cron.daily: Delayed installer does not install SSH updates as only 9 days old
2-Oct-2003 as part of cron.daily: Delayed installer installs SSH updates as they are now 10 days old

My blue-sky-dreaming ideal is to have a system whereby I could have variable delays for different packages (My main responsibility is administering a dedicated webserver, so local vulnerabilities are far less critical from my perspective than remote vulns). So for example :

Network visible things (Apache, OpenSSL, SSH) install updates after 10 days of no changes.
PHP updates after 15 days (have some apps in PHP, need more time to test these).
Everything else update after 30 days (as this is a dedicated webserver, so non-network visible vulnerabilities are less of an immediate threat).

Note that these figures are appropriate for me based on my experiences and configuration, plus the "Timing the Application of Security Patches for Optimal Uptime" paper (visible at: http://www.homeport.org/~adam/time-to-patch-usenix-lisa02.pdf - basically this paper suggests either applying updates either after 10 days, or after 30 days). However, different delays would probably be appropriate for other system administrators.

I've searched all the obvious places I can think of to see if there's a way to do this, but I haven't been able to find anything. Any help is most appreciated.

Kind Regards,
Nick.

Re: Applying Unstable --> Testing logic to Debian

Posted by Steve (82.41.xx.xx) on Mon 14 Feb 2005 at 09:15
[ Send Message | View Steve's Scratchpad | View Weblogs ]

I'm not aware of anything that will do that right now, the closest thing this reminds me of is the delayed nature of some of the pool queues used in Debian proper.

When a developer has produced a new package they upload it into the archive, and normally it goes into the archive immedietaly (unless its new, etc). Instead there are delayed queues where you can choose to upload a package so that it only enters the official archive after X days.

It seems very similar to what you're asking for. If you had a whole bunch of machines it might be effective for you to setup a mirror of the security queue - only instead of copying remote packages into it immediately (or more likely from a cron job) you would want to :

Sent an email to announce that a new package has been discovered
Only copy it into your local mirror after 5 days, or so.

That way the complexity of handling the delay is only in one place - all your machines would be set to immediately update from your local mirror.

Failing that you could use something to merely notify you that there are new updates and add an "at" job to upgrade them xx days later.

I guess the short answer is that there's nothing immediately obvious which does the job you'd like.

Steve
-- Steve.org.uk

[ Parent | Reply to this comment ]

Re: Applying Unstable --> Testing logic to Debian

Posted by Nickj (218.215.xx.xx) on Tue 15 Feb 2005 at 03:50
[ Send Message ]

Thank you for your reply and thoughts on this.

I'm wondering whether an "at" command run after a download is maybe the simplest way of doing this.

I.e.:
1) Download updated packages.
2) Set an "at" command to install those packages in 10 days time.

There are two problems I see with this though. The first is preventing the installation of superseded packages:

# cd /var/cache/apt/archives
# ls -al

Shows several situations where both older and newer versions of a package are present, such as:

-rw-r--r--    1 root     root       235078 Oct  7 20:50 libmysqlclient10_3.23.49-8.8_i386.deb
-rw-r--r--    1 root     root       235264 Jan 15 03:15 libmysqlclient10_3.23.49-8.9_i386.deb
-rw-r--r--    1 root     root       122896 Oct  7 20:50 mysql-client_3.23.49-8.8_i386.deb
-rw-r--r--    1 root     root       123080 Jan 15 03:15 mysql-client_3.23.49-8.9_i386.deb
-rw-r--r--    1 root     root        17262 Oct  7 20:50 mysql-common_3.23.49-8.8_all.deb
-rw-r--r--    1 root     root        17484 Jan 14 01:50 mysql-common_3.23.49-8.9_all.deb
-rw-r--r--    1 root     root      2800926 Oct  7 20:50 mysql-server_3.23.49-8.8_i386.deb
-rw-r--r--    1 root     root      2800998 Jan 15 03:15 mysql-server_3.23.49-8.9_i386.deb
-rw-r--r--    1 root     root        81192 Dec 25 00:45 libtiff3g_3.5.5-6.woody3_i386.deb
-rw-r--r--    1 root     root        81286 Jan  6 03:30 libtiff3g_3.5.5-6.woody5_i386.deb
-rw-r--r--    1 root     root       111096 Oct 20 00:40 libcupsys2_1.1.14-5woody10_i386.deb
-rw-r--r--    1 root     root       111224 Jan 15 19:45 libcupsys2_1.1.14-5woody12_i386.deb

These updates all happened more than 10 days apart, but if they happened less than 10 days apart, then it should abort the installation of the superseded package, and restart the 10 day countdown.

Is there a way to purge the downloaded .deb files when they are no longer the most current version of a package? I tried "apt-get autoclean", but it didn't erase them, and the man page for "apt-get clean" suggests it will delete everything, even the most recent packages. The reason for this is I was thinking that the "at" command could check if the downloaded package file was still present, and if so then install it using dpkg. That way more recent versions would cause the older versions to be deleted, thus resetting the 10 days countdown, and preventing the older packages from ever being installed.

I'm wondering whether "apt-show-versions -u" (which shows all outstanding upgrades and their version numbers) mightn't be a way to achieve this. Then any updates that don't match the output of this could be deleted from the /var/cache/apt/archives directory, so the contents of that directory would then become a listing of the most recent unapplied pending security updates.

The only problem that leaves then is one of dependencies between the updated packages. For example, suppose we have an DSA update that give us two updated packages:

mysql-server_3.23.49-8.8_i386.deb
mysql-client_3.23.49-8.8_i386.deb (assume this depends on mysql-server >= 3.23.49-8.8)

... and then suppose that before the 10 days is up, that mysql-server is superseded by an new mysql-server_3.23.49-8.9 version (but that there are no updates to the mysql-client). The installation of the mysql-client should then be delayed until the mysql-server has gone for 10 days without any further updates. To do this, I'm wondering whether there's a way to get dpkg or apt to install just the specified package files, and only if their dependencies are either already installed or are one of the other packages on the command line.

For example:

# Some command like this that should fail, because it doesn't also have mysql-server >= 3.23.49-8.8 on the command line:
dpkg -i /var/cache/apt/archives/mysql-client_3.23.49-8.8_i386.deb
# Versus some command like this that should succeed, because all dependencies are met:
dpkg -i /var/cache/apt/archives/mysql-client_3.23.49-8.8_i386.deb /var/cache/apt/archives/mysql-server_3.23.49-8.9_i386.deb

If there was some way of doing this, then I could just pass it a list of all the pending security updates older than 10 days, and let dpkg or some-related-program sort it out, but I can't readily see a way of doing this.

Kind Regards,
Nick.

[ Parent | Reply to this comment ]

Debian Administration