There are a number of things I like about FreeBSD, more than any Linux distribution I've ever used. Some of those are advantages shared by no Linux distribution I've used, and some are advantages shared by a few Linux distributions but not others — but no Linux distribution shares all of these advantages (even discounting things no Linux distribution has, like a BSD-licensed kernel).
One of the higher-level FreeBSD tools I rather like is
$ portaudit -a 0 problem(s) in your installed packages found.
The key isn't so much that no vulnerabilities were discovered on my system; rather, it's how simply, easily, and quickly I found out that I'm not currently at risk.
The canonical example from the FreeBSD Handbook of what happens when you get a security vulnerability looks like this:
$ portaudit -a Affected package: apache-1.3.29_1 Type of problem: Apache 1.3 IP address access control failure on some 64-bit platforms. Reference: <http://people.freebsd.org/~eik/portaudit/09d418db-70fd-11d8-873f-0020ed76ef5a.html> Affected package: mpg123-esound-0.59r_12 Type of problem: mpg123 vulnerabilities. Reference: <http://people.freebsd.org/~eik/portaudit/9fccad5a-7096-11d8-873f-0020ed76ef5a.html> 2 problem(s) in your installed packages found.
The importance of vulnerability tracking
Determining the security vulnerability status of software on your system, as part of your risk assessment and security maintenance strategy, is only one of many requirements of maintaining a secure system — but it's a very important requirement. You simply can't reliably fix or work around specific security problems on your systems if you don't know they exist. This is part of the reason that I wrote "How should we handle security notifications? " It's also the main reason why making the process of checking the security vulnerability status of software on your system incredibly easy (as it is with
portaudit on FreeBSD systems) is very, very important.
One of the benefits of a tool like FreeBSD's
portaudit is the fact that it reports all known vulnerabilities, without necessarily being part of the software updating process itself:
- It doesn't leave out anything that hasn't been patched yet. This can be important in cases where you are at risk, and need to employ some kind of work-around to protect yourself until a patch exists.
- It allows you to make decisions for yourself about the importance of vulnerabilities, which can fit into a larger risk assessment plan to balance capabilities against security needs.
- It lets you know when a vulnerability exists in a piece of software that you've intentionally maintained at an older version for compatibility or testing purposes, so that you can make a reasoned decision about what needs updating.
With a comprehensive software management system such as the FreeBSD ports system, this also means that even for third-party software you generally don't have to search the Web and go through individual software distributors to find vulnerabilities that may affect your system. Known vulnerabilities are brought to you, like front-door delivery service.
As I pointed out in another article, "Interface design is security design," making good security practice easy is a key factor in creating a secure computing environment. I'd have to say that, in terms of making security vulnerability auditing easy, FreeBSD definitely succeeds with
After updating the local copy of the ports tree (I use the
portsnap tool on my FreeBSD systems):
# portsnap fetch update
. . . update the portaudit database:
# portaudit -Fd
-F actually updates the database, and the
-d option prints out the creation date of the database. Once that is done, your system is ready to be checked for vulnerabilities:
# portaudit -a
With that, you get a listing of all known vulnerabilities on your system.
Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.