To Software Software - To Software-Assessment - Software/Assessment
Introduction
Description of procedures to track and apply security patches for the Operating System(s) in use on CAcert's critical servers, more specifically for Debian GNU/Linux, as currently used on CAcert's webdb server.
Tracking security patches
Security alerts and the availability of security patches are monitored by subscribing to the debian-security-announce mailing list. If necessary, all security advisories can also be consulted directly on the Debian Security Information web page. Note that many security advisories are not relevant for the webdb server, because it runs with a fairly minimal set of software packages.
On the running system, the availability of relevant security patches from the configured repositories can be determined by:
# apt-get update # apt-show-versions -u
An automatic script /etc/cron.daily/apt-warn is used to perform this check daily and inform the system administrators by e-mail about the availability of relevant security patches.
Applying security patches
Relevant security patches should be applied at the earliest convenient moment. A log should be kept of the output of the patch process, and a notice should be mailed to the cacert-systemlog@cacert.org mailing list specifying the old and new version of each upgraded package. Thus the process is:
$ LOG=OSPATCH-`date '+%Y%m%d'`.log $ script ${LOG} $ sudo apt-get update $ sudo apt-show-versions -u $ sudo apt-get upgrade -u $ exit $ chmod a-wx ${LOG} $ sudo mv ${LOG} /var/log
and e-mail the output of apt-show-versions -u to cacert-systemlog@cacert.org.
In addition, when the patch modifies operating system components which are duplicated in the chroot environment under which the web server is running, the updated components need to be propagated to the web server's chroot environment (under /home/cacert).
Other notes
Suggestions/Discussion
Some Random Notes to make this process more secure (unfortunatelly it also means more work) -- BerndEckenfels
- It should be documented what Debian Repositories are configured and the respective priority/pinning (deb lines in sources.list). It should also be configured what package signing verification is installed and used.
- I wonder why this process does not contain a Test System (staging) and a CR approval?
- The "updated components need to be propagated" needs to be automated (at least the warning if files differ)
- The above procedure should contain change tracking on a file level (i.e. new baseline for checksums on the server)
- I wonder if a more strictly enfocrd logging of root (shell) activity would avoid forgotten logs. For example it could be forbidden to run root shells, instead ask for using a logging "sudo" for each single command