On April 9, 2000, the TrustedBSD Project was announced, which replaces the FreeBSD hardening project, bringing in the POSIX.1e DAC, privilege and MAC improvements. As such, the FreeBSD Hardening Project is now defunct, please update your links.
POSIX.1e implementation underway!March 3, 1999
An implementation of POSIX.1e for FreeBSD is underway.
The FreeBSD operating system provides an excellent high-performance platform for most network services. However, the traditional security approach taken in developing FreeBSD has been that of an open system -- in the large majority of cases, restricting access unnecessarily is not an advantage. While there are no known gaping holes in the FreeBSD security architecture, it is vulnerable if a root compromise occurs. Similarly, there are many services offered that leak information that, in a secure environment, might provide attackers with more information than they strictly require as users.
The goal of the FreeBSD Hardening Project is to develop a set of modifications to the base FreeBSD system that, when applied, allow for a far more secure environment. Services would, in general, be disabled until specifically enabled -- much like modern firewall policies. Currently, the medium of choice for delivering these changes is through a port. This port would be applied only to base systems, as modifications on top of base systems would not have been accounted for in the design of the port. This is not unlike the C2 certification applying to a specific system configuration.
The FreeBSD security framework suffers from a number of significant problems:
Root compromise results in loss of trust of the system -- root is essentially unlimited in capability to change the system binaries and configuration at run time. This also includes all auditing information in the default configuration.
The default configuration for FreeBSD consistently leaks account and process information where unneeded. For example, the default configuration allows the retrieval of login information for the administration account by unknown users over the network (fingerd).
Processes on the system can retrieve extensive information about the system, and about other processes running with different UIDs, through normal setuid programs, and through liberal permissions on logs. This allows for unnecessary priveledges that might prove useful to an attacker if a service was compromised. As compromise of network services is not uncommon due to buggy code (sendmail, imapd, ...), this contingency must be allowed for on sensitive machines.
FreeBSD is sufficiently flexible to allow the implementation of many security policies -- it offers a variety of mechanisms to this end. However, those mechanisms are largely uncoordinated, and there is no central source of security policy for a machine. Similarly, while individuals have hardened their machines based on their own experience, there is no central repository for information on performing such changes.
The implementation must provide:
Easy installation on a base system. We hope to have a dialog-based interface which would allow trivial selection and installation of security policy decisions.
Multiple degrees of security. Not all users have the same requirements. A network firewall machine should have an extremely high level of security, but has less need of "features" than a multi-user network server. Similarly, determination of the source of possible attacks is imporant, and it would be desirable that system security could be tailored to those attacks.
Leave a useful system. Just because a machine is "secure" does not and should not mean it is left unusable.
Documentation. All changes made to the system must be clearly documented and rationale for the changes must be provided.
Long-term reintegration with the central FreeBSD project. Enforcing a high degree of paranoia on all users is not desirable -- security by definition requires greater understanding and involvement in a system's design and implementation. Rather than expect this of all users of FreeBSD (many of whom are hobbyists, or work in an environment where these changes would be unhelpful or restrictive), making the Hardening Project a seperate port seemed desirable. However, it is expected that some of the changes might be useful in the regular distribution.
Our goal is to provide two tools -- one that allows the determination of a system policy for security, and then other to implement that policy. In this manner, a centrally managed security policy could be developed, and then applied to a larger number of workstations or servers.
The initial implementation of a subset of the desired features is now under way, but is not yet available. This implementation will include a rudimentary policy manager to manage inetd.conf daemons and setuid/setgid binaries, along with information on the effects of disabling or limiting the scope of these features. Kernel modifications will not be available in this initial release.
A sample policy of one possible policy description language may be found here; a sample policy for a hardened system may be found here. This language definition is still in flux, and may change daily.
Not much is available for download at this point.
Discussion of the FreeBSD Hardening Project may be found on the freebsd-security mailing list.
Email Robert Watson for more information or to suggest changes to this page. The freebsd-security mailing list is our playground.
Last modified: Sat Nov 6 16:38:38 EST 1999