www.taosecurity.com/keeping_freebsd_up-to-date.html
ps 05 December 2004 Introduction An important system administration task, and a principle of running a def ensible network, is keeping operating systems and applications up-to-dat e Running current software is critical when older services are vulnerab le to exploitation. Obtaining new features not found in older applicatio ns is another reason to run current software. Fortunately, open source s oftware offers a variety of means to give users a secure, capable comput ing environment. This article presents a multiple ways to keep the FreeBSD operating syste m up-to-date. I take a FreeBSD 521 RELEASE system through a subset of security advisories to explain the different sorts of patches an adminis trator might apply. In a future article I plan to describe how to use th e FreeBSD ports tree and related tools to keep non-OS applications up-to -date. At the time of writing FreeBSD 53 RELEASE is about a mon th old, and only two security advisories have been published thus far. R eaders wondering why someone might want to install an "old" OS version c an imagine that there might be an application supported only on FreeBSD 521 and not yet officially ready for 53, prompting an administrator t o run a 521 box. All of the work done in this article was done remotely via OpenSSH. One d anger of performing remote upgrades is losing connection during a critic al phase of the process. One software-based way to deal with this issue is to conduct all remote upgrades within a screen session.
The screen program has suffered security problems in the past, so balance its features against the possi ble risks. My advice on administering this reference platform is based on deploying FreeBSD on servers, workstations, and laptops since 2000. The article re presents mix of my interpretations of official FreeBSD documentation, in puts from mentors, and the result of my own experimentation and deployme nt strategies. This guide cannot be anywhere near a complete reference o n keeping FreeBSD up-to-date or maintaining a secure system. I strongly recommend reading the excellent FreeBSD Handbook as well as the multiple helpful published books on FreeBSD. FreeBSD Versions Before explaining ways to keep the FreeBSD OS up-to-date, I must briefly expand on the idea of the term "up-to-date." Thanks to FreeBSD's open so urce development methodology, any version of FreeBSD is available via ch eck out from the Concurrent Versions System (CVS).
Linux users should note that these CVS revision tags do not pertain to th e FreeBSD kernel alone. FreeBSD is developed as an integrated system, wi th a kernel matching userland tools. One should not run a kernel compile d for FreeBSD 53 RELEASE on a CURRENT machine. The kernel and all userl and utilities are meant to be upgraded simultaneously, and must be kept synchronized. FreeBSD strongly encourages u sers to always keep the userland and kernel in sync using the methods ex plained in the Handbook and elaborated upon in this document. When thinking of what it means to be "up-to-date," one can see that the " oldest" version of FreeBSD as of version 53 is that which was most rece ntly "pressed to CD" -- RELENG_5_3_0_RELEASE or FreeBSD 53 RELEASE. The "newest" would be HEAD or CURRENT, a constantly moving target modified and improved on a daily basis. How does an administrator decide what to run on her machines? I prefer to begin a system's life by installing RELEASE software, like Fr eeBSD 53 RELEASE. As long as the systems performs as I would expect it to, I then track the RELENG_5_3 or "security" branch. This allows me to incorporate critical bug and security fixes that could jeopardize the sy stem. Occasionally I may encounter a system that requires a feature (like suppo rting a new piece of hardware) not present in the RELEASE or security br anches. In cases where that feature is supported by STABLE, I will upgra de to that branch. In the rare cases where not even STABLE has the featu re I need, I might install a snapshot of the CURRENT branch. I do not re commend running CURRENT in production environments as it is not supporte d like the RELEASE or STABLE versions are. Learning About Security Issues FreeBSD security advisories are published at the FreeBSD security page an d at the freebsd-security-notifications mailing list.
The advisories provide background, a problem desc ription, and impact statement, workaround advice, a solution to fix the problem, and correction details. We'll take a closer look at an actual s ecurity advisory when we learn how to apply patches manually to the oper ating system. Starting with the Installation Let's start with the most common deployment scenario, using FreeBSD 521 RELEASE as our reference platform. For this version, the CVS tag is 5_2 _1 for the version shipped on CD and 5_2 for the security branch. She installs the Developer distribution set so she has "Full sources, b inaries and doc but no games." com:/usr/obj/usr/src/sys/GENERIC i386 She does not need to modify the kernel and is running the GENERIC version shipped with the OS. She does not need any enhancements offered by the STABLE tree and decides to track the 52 security branch. Binary OS and Userland Updates with FreeBSD Update Administrators who begin with a RELEASE system, who do not make any chang es to the FreeBSD GENERIC kernel, and who have not made any changes to t he userland, have a strong case for using binary upgrades. Binary upgrad es replace the files copied from the original RELEASE CD-ROM (for exampl e) with upgraded versions patched to address security issues. Using Colin Percival's FreeBSD Update tool, our administrator can quickly bring the system fully up-to-date with respect to the 52 security bran ch.
The administrator installs and runs FreeBSD Update by retrieving the tool as a remote, precompiled package. sample extract: /usr/local/share/doc/freebsd-update/LICENSE extract: /usr/local/share/doc/freebsd-update/README extract: /usr/local/share/doc/freebsd-update/VERSION extract: CWD to . Package freebsd-update-14 registered in /var/db/pkg/freebsd-update-14 Before you can use this, you will have to create an update configuration file specifying the server to fetch updates from and the trusted public key fingerprint. conf Finally she is ready to retrieve and apply updates: freebsd521:/root# freebsd-update fetch Fetching public key... Updates fetched To install these updates, run: '/usr/local/sbin/freebsd-update install' Don't forget to rebuild any statically linked ports to use the updated libraries after you install them. ko), and a variety of binaries, libraries, and man pages. Next the administrator applies the patches: freebsd521:/root# freebsd-update install Backing up /boot/kernel/kernel... A reboot is needed becau se the kernel itself was updated. You can verify that your FreeBSD system required no other binary upgrades b y running FreeBSD Update again: freebsd521:/root# freebsd-update fetch Fetching updates signature... No updates available Since no updates are available, the system is patched. FreeBSD Update is a simple yet powerful way to keep a FreeBSD machine ali gned with the security branch. Its primary drawback is its inability to update a kernel customized by the system administrator. Since it's not p ossible for Colin to imagine all of the different kernel modifications a dministrators might make, he is restricted to building binary upgrades o f the stock GENERIC kernel. While the GENERIC kernel is appropriate for many deployments, its lack of IPSec support, for example, might prompt a n administrator to deviate from the GENERIC path. FreeBSD Update cannot handle changes to the userland that deviate from wh at was packaged with a RELEASE, either. If an administrator tinkers with a driver or tool, and that file subsequently requires a security fix, F reeBSD Update will not try to replace it be default. However, FreeBSD Update's author Colin Percival notes: "FreeBSD Update can be forced to download security fixes for files which have been locally modified by using the --branch option starting with ve rsion 15 The "branches" here are "nocrypto", "crypto", "krb4", and "kr b5"; most users would be runnin...
|
http://csua.com/feed/