1.1. What Is System Security?

Security professionals break the term security into three parts: confidentiality, integrity, and availability. This "CIA Triad" is a set of security requirements; if you're not taking into account all three of these concerns, you're not working towards providing security. We offer a lot of recommendations in this book that should help you work towards building secure systems, but we don't tell you how these recommendations fit in with the CIA Triad. That's not what this book is about, and it would detract from the real message. Nevertheless, as you're looking at building encrypted tunnels for transferring files, jailing applications, and so on, think about what part of the Triad you're focusing on. Make sure you've addressed all three parts before your project is done.

Whether we're talking about physical security, information security, network security, or system security, the CIA Triad applies. The question is, exactly how does it apply to system security?

1.1.1. Confidentiality

Confidentiality is all about determining the appropriate level of access to information. Confidentiality is often implemented at the most basic level on FreeBSD and OpenBSD systems by traditional Unix permissions. There are a variety of files scattered across the filesystem that are readable only by the root user. Most notable, perhaps, is /etc/master.passwd, which contains hashes for users' passwords. The vast majority of files are readable by everyone, however. Even system configuration files like /etc/resolv.conf, /etc/hosts, and so on are world readable. Is this wrong? Not necessarily. Again, confidentiality isn't about having to protect data from prying eyes; it's about classifying data and making sure that information deemed sensitive in some way is protected appropriately.

Filesystem level protections are of course only one facet of confidentiality. Data may be exposed through some service designed to serve information like DNS, or a web server. In these cases, the method you employ to protect data won't necessarily be filesystem permissions; perhaps you'll control what systems are allowed to query your DNS server, or which web-authenticated users are permitted to view a certain document tree. When you need to protect data from eavesdropping as it moves across a network, you'll probably use encryption. When implemented appropriately, it helps ensure that only the intended recipient can read the transmitted data.

1.1.2. Integrity

Data integrity relates to trust. If you cannot guarantee the integrity of some information on your system, you can't trust it. Consequently, resources for which integrity is an important issue need to be identified and appropriately protected against modification.

Confidentiality may not have been an issue for your /etc/resolv.conf file. Allowing users to see what resolvers your system depends on is okay. Allowing users to modify the list of resolvers is not! Your system's resolvers are a data source. When you access a server providing anonymous CVS access to your OpenBSD sources, your system will ask one of the servers listed in /etc/resolv.conf to find the IP address for the name you provided. If you can't guarantee the integrity of the data in this file, you can't trust the IP address you get from the resolver. As a consequence, you can't trust the sources you download either.

Like confidentiality, the filesystem permissions model helps enforce data integrity. Unfortunately file permissions aren't enough by themselves. If someone has broken through your filesystem protections somehow, you won't know that your data has been tampered with. That is, not without good auditing. Moreover, you won't be able to restore a known good configuration without data backups.

Data integrity is also an issue during network transfers. How can you be sure that the information has not been modified in transit? The BSD operating systems will provide "signatures," which uniquely identify file distributions. When you download a package or source tarball or install a port, you can check your local files against the remote signatures. If it's a match, your file has not been modified while in transit.

1.1.3. Availability

Often overlooked by administrators, availability is the last key component of security. Protecting your systems from information disclosure and tampering is important but not sufficient. If a user on your system "accidentally" copies his 120GB MP3 music collection to your file server and you run out of disk space on /, your system will suddenly cease being useful. If you had separated your home directories into their own partition, and additionally configured filesystem quotas, this would not have been a problem.

Availability does not only pertain to services, it can also apply to data, though most examples you might immediately think of are really data integrity issues. What would happen if a virus infected your workstation and destroyed the only private keys that decrypt vital data? You probably have a backup of that encrypted file and have otherwise taken care of integrity issues, but suddenly that data may as well have been deleted. It's no longer available for use.

System availability can be one of the most difficult areas of providing system security. The number of ways (both physical and electronic) an attacker can make your server unavailable is staggering.

1.1.4. Summary

So, after all this, what is system security? For our purposes, providing "system security" is about responding to risks that threaten the confidentiality or integrity of data that resides on or passes through our systems, and working to guarantee the availability of the services and data. If you made it through this section, congratulations. This is pretty dry stuff, but it's important. We won't explicitly talk about the elements of the CIA Triad in this book, but we encourage you to keep these principles in mind when working on protecting your systems.