You should strive to keep your system secure by monitoring its usage and also the vulnerabilities that might affect it, patching them as soon as patches are available. Even though you might have installed a really secure system initially you have to remember that security in a system degrades with time, security vulnerabilities might be found for exposed system services and users might expose the system security either because of lack of understanding (e.g. accessing a system remotely with a clear-text protocol or using easy to guess passwords) or because they are actively trying to subvert the system's security (e.g. install additional services locally on their accounts).
10.1.1. Tracking security vulnerabilities
Although most administrators are aware of security vulnerabilities affecting their systems when they see a patch that is made available you can strive to keep ahead of attacks and introduce temporary countermeasures for security vulnerabilities by detecting when your system is vulnerable. This is specially true when running an exposed system (i.e. connected to the Internet) and providing a service. In such case the system's administrators should take care to monitor known information sources to be the first to know when a vulnerability is detected that might affect a critical service.
Concious administrators can use that information to determine which security bugs might affect the system they are managing, determine the severity of the bug and apply (if available) temporary countermeasures before a patch is available fixing this issue.
Notice, however, that the information tracked by the Debian Testing Security Team only involves disclosed vulnerabilities (i.e. those already public). In some occasions the Debian Security Team might be handling and preparing DSAs for packages based on undisclosed information provided to them (for example, through closed vendor mailing lists or by upstream maintainers of software). So do not be surprised to find security issues that only show up as an advisory but never get to show up in the security tracker.
10.1.2. Continuously update the system
10.1.2.1. Manually checking which security updates are available
Debian does have a specific tool to check if a system needs to be updated but many users will just want to manually check if any security updates are available for their system.
If you have configured your system as described in
Sección 4.2, “Ejecute una actualización de seguridad” you just need to do:
# apt-get update
# apt-get upgrade -s
[ ... review packages to be upgraded ... ]
# apt-get upgrade
# checkrestart
[ ... restart services that need to be restarted ... ]
The first line will download the list of packages available from your configured package sources. The
-s will do a simulation run, that is, it will
not download or install the packages but rather tell you which ones should be downloaded/installed. From the output you can derive which packages have been fixed by Debian and are available as a security update. Sample:
# apt-get upgrade -s
Reading Package Lists... Done
Building Dependency Tree... Done
2 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Inst cvs (1.11.1p1debian-8.1 Debian-Security:3.0/stable)
Inst libcupsys2 (1.1.14-4.4 Debian-Security:3.0/stable)
Conf cvs (1.11.1p1debian-8.1 Debian-Security:3.0/stable)
Conf libcupsys2 (1.1.14-4.4 Debian-Security:3.0/stable)
Notice that you will need to reboot your system if there has been a kernel upgrade.
10.1.2.2. Checking for updates at the Desktop
Since Debian 4.0 lenny Debian provides and installs in a default installation update-notifier. This is a GNOME application that will startup when you enter your Desktop and can be used to keep track of updates available for your system and install them. It uses update-manager for this.
In a stable system updates are only available when a security patch is available or at point releases. Consequently, if the system is properly configured to receive security updates as described in
Sección 4.2, “Ejecute una actualización de seguridad” and you have a cron task running to update the package information you will be notified through an icon in the desktop notifcation area.
The notification is not intrusive and users are not forced to install updates. From the notification icon a desktop user (with the administrator's password) can access a simple GUI to show available updates and install them.
This application works by checking the package database and comparing the system with its contents. If the package database is updated periodically through a cron task then the contents of the database will be newer than the packages installed in the system and the application will notify you.
Apt installs such a task (/etc/cron.d/apt) which will run based on Apt's configuration (more specifically APT::Periodic). In the GNOME environment this configuration value can be adjusted by going to System > Admin > Software origins > Updates, or running /usr/bin/software-properties.
If the system is set to download the packages list daily but not download the packages themselves your
/etc/apt/apt.conf.d/10periodic should look like this:
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "0";
Users of the KDE desktop environment will probably prefer to install adept and adept-notifier instead which offers a similar functionality but is not part of the standard installation.
10.1.2.3. Automatically checking for updates with cron-apt
Another method for automatic security updates is the use of cron-apt. This package provides a tool to update the system at regular intervals (using a cron job), and can also be configured to send mails to the system administrator using the local mail transport agent. It will just update the package list and download new packages by default but it can be configured to automatically install new updates.
Notice that you might want to check the distribution release, as described in
Sección 7.5.3, “Per distribution release check”, if you intend to automatically updated your system (even if only downloading the packages). Otherwise, you cannot be sure that the downloaded packages really come from a trusted source.
10.1.2.4. Automatically checking for security issues with debsecan
The
debsecan program evaluates the security status of by reporting both missing security updates and security vulnerabilities. Unlike
cron-apt, which only provides information related to security updates available, but this tool obtains information from the security vulnerability database maintained by the Debian Security Team which includes also information on vulnerabilities which are not yet fixed through a security update. Consequently, it is more efficient at helping administrators track security vulnerabilities (as described in
Sección 10.1.1, “Tracking security vulnerabilities”).
Upon installing the Debian package debsecan, and if the administrator consents to it, it will generate a cron task that will make it run and send the output to a specific user whenever it finds a vulnerable package. It will also download the information from the Internet. The location of the security database is also part of the questions ask on installation and are later defined /etc/default/debsecan, it can be easily adjusted for systems that do not have Internet access so that they all pull from a local mirror so that there is a single point that access the vulnerability database.
Notice, however, that the Security Team tracks many vulnerabilities including low-risk issues which might not be fixed through a security update and some vulnerabilities initially reported as affecting Debian might, later on, upon investigation, be dismissed. Debsecan will report on all the vulnerabilities, which makes it a quite more verbose than the other tools described above.
10.1.2.5. Other methods for security updates
10.1.3. Avoid using the unstable branch
Unless you want to dedicate time to patch packages yourself when a vulnerability arises, you should not use Debian's unstable branch for production-level systems. The main reason for this is that there are no security updates for unstable.
The fact is that some security issues might appear in unstable and not in the stable distribution. This is due to new functionality constantly being added to the applications provided there, as well as new applications being included which might not yet have been thoroughly tested.
In order to do security upgrades in the unstable branch, you might have to do full upgrades to new versions (which might update much more than just the affected package). Although there have been some exceptions, security patches are usually only back ported into the stable branch. The main idea being that between updates, no new code should be added, just fixes for important issues.
10.1.4. Security support for the testing branch
If you are using the
testing branch, there are some issues that you must take into account regarding the availability of security updates:
When a security fix is prepared, the Security Team backports the patch to stable (since stable is usually some minor or major versions behind). Package maintainers are responsible for preparing packages for the unstable branch, usually based on a new upstream release. Sometimes the changes happen at nearly the same time and sometimes one of the releases gets the security fix before. Packages for the stable distribution are more thoroughly tested than unstable, since the latter will in most cases provide the latest upstream release (which might include new, unknown bugs).
Security updates are available for the unstable branch usually when the package maintainer makes a new package and for the stable branch when the Security Team make a new upload and publish a DSA. Notice that neither of these change the testing branch.
If no (new) bugs are detected in the unstable version of the package, it moves to testing after several days. The time this takes is usually ten days, although that depends on the upload priority of the change and whether the package is blocked from entering testing by its dependency relationships. Note that if the package is blocked from entering testing the upload priority will not change the time it takes to enter.
This behavior might change based on the release state of the distribution. When a release is almost imminent, the Security Team or package maintainers might provide updates directly to testing.
Additionally, the
http://secure-testing-master.debian.net can issue Debian Testing Security Advisories (DTSAs) for packages in the
testing branch if there is an immediate need to fix a security issue in that branch and cannot wait for the normal procedure (or the normal procedure is being blocked by some other packages).
Users willing to take advantage of this support should add the following lines to their
/etc/apt/sources.list (instead of the lines described in
Sección 4.2, “Ejecute una actualización de seguridad”):
deb http://security.debian.org testing/updates main contrib non-free
# This line makes it possible to donwload source packages too
deb-src http://security.debian.org testing/updates main contrib non-free
10.1.5. Automatic updates in a Debian GNU/Linux system
First of all, automatic updates are not fully recommended, since administrators should review the DSAs and understand the impact of any given security update.
If you want to update your system automatically you should:
Configure apt so that those packages that you do not want to update stay at their current version, either with apt's pinning feature or marking them as hold with aptitude or dpkg.
To pin the packages under a given release, you must edit
/etc/apt/preferences (see
apt_preferences(5)) and add:
Package: *
Pin: release a=stable
Pin-Priority: 100
FIXME: verify if this configuration is OK.
The
-y option will have
apt assume 'yes' for all the prompts that might arise during the update. In some cases, you might want to use the
--trivial-only option instead of the
--assume-yes (equivalent to
-y).
Configure
debconf so no questions will be asked during upgrades, so that they can be done non-interactively.
Check the results of the cron execution, which will be mailed to the superuser (unless changed with MAILTO environment variable in the script).
A safer alternative might be to use the -d (or --download-only) option, which will download but not install the necessary packages. Then if the cron execution shows that the system needs to be updated, it can be done manually.
However, this is not recommended for unstable without careful analysis, since you might bring your system into an unusable state if some serious bug creeps into an important package and gets installed in your system. Testing is slightly more secure with regard to this issue, since serious bugs have a better chance of being detected before the package is moved into the testing branch (although, you may have no security updates available whatsoever).
If you have a mixed distribution, that is, a
stable installation with some packages updated to
testing or
unstable, you can fiddle with the pinning preferences as well as the
--target-release option in
apt-get to update
only those packages that you have updated.
