How to emerge the security updates only
4 August 2007
Security updates are good
In Gentoo Linux, there is, of course, a graphical frontend to do updates (called 'Porthole'), however the command line interface is called emerge.
The object of the command can be a package name ('ebuild' in Gen-speak) for example, gedit or epiphany, or it can be a 'set'. There are two sets, system and world.
The system set is the bare basics needed for the system to be able to run and to recompile itself. The world set is everything you have installed already.
I moan often that that this is a bit blunt, a bit un-Gentoo-ish, Gentoo is all about choice after all. Sometimes, when you have a system set up and optimised for a specific function, it may well be working and you want it to change as little as possible. If it is a networked device, you only want to do the updates necessary to keep the computer secure; you do not want new features and as few disruptive changes as possible.
The great thing about computers is that there is always a way to do something. However, the way is often just hard to figure out or you have not bumped into a person that knows the answer yet. So if you moan to everyone, someone will give up and tell you. Today I moaned on IRC and igli told me the answer.
gentoolkit is a "collection of administration scripts for Gentoo", out of interest, it has a sister package called gentoolkit-dev which is a "collection of developer scripts for Gentoo". Also interesting is that many (all?) of these tools are in Python.
One of the tools in gentoolkit is called glsa-check.
Enter the Dragon
Gentoo Linux Security Announcements (GLSAs) are short reports written by the Gentoo security team, they help us keep secure and are also a respected form of information in the wider mainstream security community. (For more about the GLSAs, read my recent interview with Matt Drew of the Gentoo Linux Security Team).
As well as being published online, the GLSAs are pushed out directly to users through portage updates. glsa-check is a fabulous little tool that aims to allow you to automate the monitoring of the GLSAs, and in turn, act on them automatically.
gsla-check quick guide
The tool has lots of options, but I will stick to the basics here.
Firstly, we can test the system against the security reports:
``$ glsa-check -t all
This system is affected by the following GLSAs:
200707-05
200707-13
So this server has two issues, the report from the 5th July and the one from the 13th July. Let's see what they are:
``$ glsa-check -l affected
- 200707-05 [N] Webmin, Usermin: Cross-site scripting vulnerabilities (
- app-admin/webmin app-admin/usermin )
200707-13 [N] Fail2ban: Denial of Service ( net-analyzer/fail2ban )``
To read the full reports we can type: glsa-check -d affected
These reports are well structured and formally written. Therefore if you work in an environment with change management and you have to write a report for every change you make, these may be dead handy to cut and paste from.
Now we want to see how the system proposes to fix them:
`` ~ $ glsa-check -p affected
Checking GLSA 200707-05
The following updates will be performed for this GLSA:
app-admin/webmin-1.350 (1.320)
Checking GLSA 200707-13
The following updates will be performed for this GLSA:
net-analyzer/fail2ban-0.8.0-r1 (0.7.9)
Webmin will be upgraded from version 1.320 to 1.350, and fail2ban will upgrade from 0.7.9 to 0.8.0-r1.
We are happy with that, so let's run the fixes:
# glsa-check -f affected
The fix element of it is still labelled as experimental, but it worked well for me. Of course, this was a verbose way of doing this for the sake of the tutorial, in normal usage, one or two of the commands will do the trick.
As well as being helpful for dedicated machines, the glsa-check command can also help tide over a system until a set update time (e.g. once a quarter). I'll keep using it and I'll let you know how I get on with it.
