By Jeffrey Carl
Boardwatch Magazine was the place to go for Internet Service Provider industry news, opinions and gossip for much of the 1990s. It was founded by the iconoclastic and opinionated Jack Rickard in the commercial Internet’s early days, and by the time I joined it had a niche following but an influential among ISPs, particularly for its annual ranking of Tier 1 ISPs and through the ISPcon tradeshow. Writing and speaking for Boardwatch was one of my fondest memories of the first dot-com age.
While most Freenix admins are used to securing their servers, there is a “higher” world of security that has never been touched by free *nixes. The realm of “trusted” operating systems, long the province only of military and other ultra-secure environments, represents a security level beyond that of all but a few operating systems. Now, however, the TrustedBSD (http://www.trustedbsd.org/) project is working to bring that security level to FreeBSD and other *BSD OSes. If you operate a multi-user environment and you’re looking for the optimum in security, then learning about TrustedBSD is a very exciting project.
I asked Robert Watson, one of TrustedBSD’s lead developers, to describe the project for Internet providers and other BSD server users:
Q: What is the purpose of TrustedBSD?
A: TrustedBSD provides a set of security extensions to the FreeBSD operating system under a liberal license. Targeting both military and commercial models, TrustedBSD includes traditional trusted operating system features, as well as an extensible authorization architecture to simplify development of new security features. The TrustedBSD project provides an organizational framework through which to discuss, design, develop, and document these extensions.
Q: What is the Common Criteria for Information Technology Security Evaluation (CCITS)? What does it mean to “real world” uses of the OS?
A: The Common Criteria (“CC”) are a set of security description and evaluation documents developed by the United States and other governments, as well as ISO standards. Using the CC, you can use a common terminology to describe specific sets of features and degrees of evaluation. Many readers will be familiar with the Orange Book (and entire Rainbow Series) which can be considered precursors to the CC in the United States. While the Orange Book largely targeted military applications, the CC really provides a language for setting goals and determining if they have been achieved, rather than prescribing a particular set of features required for a given certification. Unlike the Orange Book, TrustedBSD specifically targets commercial and network-centric environments.
TrustedBSD is being developed with this vocabulary and evaluation system in mind, as the CC by definition provides a common criteria for understanding security products. At this time, no formal evaluation is planned, as formal evaluation requires substantial investment of resources, including financial resources. However, TrustedBSD will make an excellent candidate for evaluation. It is possible that companies choosing to resell TrustedBSD may seek formal evaluation [as a “trusted” operating system].
Q: What benefits will the TrustedBSD extensions to FreeBSD provide to admins using FreeBSD as an Internet server?
A: It is fair to say that some features of TrustedBSD will have an immediate impact on securing every-day server systems. Other features will come into play only in extremely security-centric contexts, such as military, electronic commerce, and banking environments. Regular systems may see the use of least privilege capabilities rather than volumes of less safe setuid and setgid programs. Similarly, they may take advantage of ACLs on files allowing more flexible discretionary access control. They may also take advantage of auditing features for intrusion detection. However, they are less likely to take advantage of more intrusive functionality, such as the confidentiality and integrity-oriented mandatory access policies that will be implemented.
Q: Why should an administrator of a FreeBSD web/mail/etc. server use the TrustedBSD extensions to the OS?
A: It is the intent of the TrustedBSD project to make almost all code developed for TrustedBSD available as part of the base FreeBSD operating system. Thus, all users of FreeBSD will benefit from the project by virtue of using FreeBSD. However, specific advantages, as described above, include the ability to more generally specify permissions on files and allow users to more easily manage resources, and to be able to run far less code with root privileges. As such, administrators taking advantage of this functionality will be able to run a more secure system.
A recent paper from Argus Systems, a commercial provider of trusted extensions for Solaris, described how use of mandatory integrity policies could have protected against the recent penetration of the Apache Project’s web server. Many of the same protection services will be available as part of TrustedBSD.
Q: What is the downside, if any, in installing the TrustedBSD extensions? Is administration significantly more complex? Are there any performance penalties involved?
A: Improved security is almost always a tradeoff against improved usability. That said, one important goal of TrustedBSD is to make the feature set of a trusted operating system easily accessible to users of a widely distributed free operating system. Any changes in system behavior will require administrators to understand the differences, but in most cases the differences will not be as substantial. Administrators will need to learn how to read, manipulate, and back up Access Control Lists (ACLs) on files, and understand how capabilities on files behave.
Performance implications depend on the feature in question: support for most new security checks introduces little or no overhead. However, features such as fine-granularity auditing require creation and management of large quantities of data. Performance-sensitive sites may wish to avoid using some features, such as auditing, as a result. We anticipate producing comprehensive evaluations of the performance impact as code becomes available.
Q: Are the TrustedBSD extensions planned to be architecture-specific? e.g., are the efforts of TrustedBSD only for i386 machines, or are they portable to other architectures that FreeBSD may be ported to?
The code base is intended to be architecture-neutral, and is written entirely in portable C. i386 platforms are the primary ones in use for development, but we also have access to Alpha-based systems for testing. As TrustedBSD’s supporting infrastructure allows for third-party extension, it is possible that third party security providers might distribute extension in binary-only form, but all base code will be freely available in source form.
Formal evaluation for certification requires selection of specific hardware, as whole systems are evaluated rather than purely software products.
Q: Does the TrustedBSD project intend on making its extensions portable to OpenBSD/NetBSD/Apple Darwin? What are the barriers to porting them?
A: TrustedBSD is made up of a number of components, some of which do require extensive modifications to the kernel structure. However, where such changes are made, they will improve kernel modularity and extensibility, supporting modular insertion of TrustedBSD components. If these modularity changes are introduced in other *BSD kernels, they can be used to support the higher level functionality. As the *BSD kernels are relatively close in structure, this task is well within the realm of possibility. The KAME IPv6/IPsec implementation is an example of a project that has successfully developed software for multiple BSD platforms. The BSD-style license used in TrustedBSD should pose no problem for integration with almost any other project, open source or commercial, and the TrustedBSD project would be glad to see and assist in integration into other operating systems.
Q: Do the TrustedBSD extensions to *BSD open the doors to any new uses for the OS? e.g., Are there any tasks to which the existing BSD flavors were unsuited to before for which they are now suitable?
A: Yes, it does, as it opens to doors to uses that have more demanding security requirements. Examples include banking, military, and electronic commerce. That is not to say that FreeBSD wasn’t used there before, as it was already a very qualified OS for these environments, but his provides a higher degree of assurance. An extensible security infrastructure will make FreeBSD/TrustedBSD a more appealing platform for security research and development, also.
If formally evaluated, then it would be open for use on classified networks in ways in which it currently isn’t usable.
Q: How does TrustedBSD compare to OpenBSD’s security goals? Are they competitive projects or complementary projects?
A: Complementary. To our knowledge, OpenBSD has really taken quite a different approach to security: fine-grained source code auditing and integration of cryptography. TrustedBSD introduces new authorization models, as well as auditing. While we won’t be porting the changes over to OpenBSD at this time, this doesn’t mean others can’t, or that we won’t port them in the future.
Q: How many active contributors are there to the TrustedBSD project? What areas are you looking for contributors to?
A: TrustedBSD has a relatively small developer community, although we hope it will grow as interest grows. At this point, the number of active developers is around 6 to 10, but there is substantial design discussion on our mailing list from a far larger group bringing experience from a variety of other platforms. There is also substantial interest in cross-platform portability for applications.
At this point, contributors should have strong kernel and application security experience; in particular, we’re interested in developers who have past experience with trusted operating systems. As the project progresses and the kernel component reaches greater maturity, we’ll be interested in application programmers to help adapt existing applications for any changes in the trusted OS environment. As there is interest in portable APIs, we hope to be able to leverage other work in this area.
Q: What are TrustedBSD’s goals for the next six months/year/unspecified dates in the future?
A: As with all operating system scale projects, TrustedBSD will involve an iterative development process, with features becoming available over time. We feel that the current goals can be broken down conceptually into a number of implementation phases:
• In the first phase, the goal is to introduce TrustedBSD security changes directly and within the context of the existing FreeBSD security implementation. This phase is well underway, and will result in a usable, secure system. However, the goal of this phase is to gain both development and operational experience: while some of this code will be integrated into the base system (some already has – support for extended file attributes, and ACL interfaces), the majority will be made available via seperate distribution mechanisms.
• In the second phase, the goal is to generate stronger security infrastructure in the kernel, aiming for greater generalization and modularity. In this phase, we build on the practical development experience in the first phase, having a strong understanding of the requirements base on having implemented the same features. One of the main targets of this phase is a generalized kernel authorization framework, allowing modular and pluggable security extensions to be introduced without substantial source modification (as required in the first phase). This will allow both the TrustedBSD project, and third party developers and vendors, to distributed FreeBSD security enhancements with substantially lower development and maintenance costs.
The first phase is well underway — some interfaces (in particular, for ACLs) were included in 4.0-RELEASE, and supporting infrastructure such as extended file attributes have been committed to the FreeBSD 5.0-CURRENT development branch. Support for fine-grained least privilege (a variant of POSIX.1e capabilities), native ACL support in the FFS file system, fine-grained event auditing, and MLS MAC policy support is in the works. We see a time frame for the completion of the implementation of this component within 12 months; however, one aspect to trusted operating systems is strong supporting documentation, including design, implementation, and operation. Completing this documentation may take additional time.
The second phase is currently under design–we’ve gained substantial experience in that which we have completed of the first phase, and are ready to begin discussing the stronger and more general abstractions in the second phase. By the time this interview is published, drafts for at least the modular authorization system will be under discussion on the TrustedBSD mailing lists. So far, the results look promising. We hope to have a first prototype of the generalized authorization system completed within six months, and to being migrating the security models implemented in the first phase over to this mechanism shortly thereafter.
We hope to present a number of papers detailing aspects of the TrustedBSD project at the BSD Con 2000 conference in October.