Tag: FreeBSD

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.

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.

Confirming a deal that had been whispered about among the BSD Unix community for months, Berkeley Software Design, Inc. (BSDI) and Walnut Creek CD-ROM announced on March 9 that they would merge to form a new company under the BSDI name. The significance of the announcement lies in that it brings the vendor of commercial BSD-based systems (BSDI’s BSD/OS operating system) together with the primary distributor of the largest free BSD variant (FreeBSD), signaling a major push toward unity among the BSD Unix flavors. 

The move also opens the door to more intermingling of code between the two OSes, since some of FreeBSD’s key developers were employed by Walnut Creek and will now be employed by BSDI, and members of BSDI’s BSD/OS engineering team may be contributing code to FreeBSD. In a separate move, Walnut Creek’s Slackware Linux distribution will be spun off into a separate company, run by longtime Slackware chief Patrick Volkerding.

In the short term, users of FreeBSD and BSD/OS won’t see much change to the current products (FreeBSD 4.0 and BSD/OS 4.1). BSDI will continue to offer their commercial BSD/OS and provide paid support and consulting, while FreeBSD will remain free. However, BSDI will soon offer commercial support options for FreeBSD – potentially paving the way for FreeBSD’s entry into the enterprise market in the same way that commercial support for Linux from RedHat, LinuxCare and others did for Linux. Just as important to the enterprise market, BSDI CEO Gary Johnson said that there are plans to implement a “BSD engineer” certification program by the end of Q2 2000.

In the longer term, the move offers a wealth of potential possibilities by placing the resources of a well-funded corporate entity behind promotion of BSD Unix and encouraging commonality between the OSes. BSDI has said that it will work to develop a common Application Binary Interface (ABI) between FreeBSD and BSD/OS, enabling an application written for one OS to run on the other without any modification. While specifics are still very much up in the air, it is likely that some elements from each OS will find their way into the other, over the course of the next few OS releases. 

Unconfirmed possibilities include extending FreeBSD’s hardware support with the addition of some BSD/OS code, and making user-friendly elements like the FreeBSD “ports collection” software installation scheme available as an optional add-on to BSD/OS. Still, BSDI is adamant that the merger won’t make users of FreeBSD or BSD/OS sacrifice any of the qualities they treasure in their OS of choice.

Most exciting for many *BSD users is the likelihood that many of the “old school” computer scientists who were part of the UC Berkeley Computer Science Research Group (CSRG) that developed BSD Unix and are currently affiliated with BSDI will be brought into the BSD community. While BSDI hasn’t firmed up its message about which OS to push to what constituency, it is likely that FreeBSD will continue to appeal to the open-source community while BSD/OS will be aimed at commercial and enterprise users. 

Why was the merger done? To paraphrase Benjamin Franklin, the BSDs must all hang together, or surely they will hang separately. BSDI says that, between the two operating systems, there are at least two million BSD servers running out there. BSDI cites their collective market share as 15 percent of all Internet sites, as well as being used by nine out of ten ISPs or NSPs. Between the two OSes, customers include Microsoft Hotmail (which reportedly tried to convert to Windows NT but reverted to FreeBSD after numerous problems), UUnet and Yahoo! (which also made an equity investment into the new BSDI). 

Still, the public presence of BSD Unix outside these groups is nearly nil, while Linux has garnered massive mindshare. “BSD is pervasive throughout the Internet … but the world at large doesn’t know it,” said BSDI Marketing Manager Kevin Rose. While this can be attributed to large number of factors, it lies largely in the fact that commercial BSD/OS has never had mass mindshare, while the free BSD variants with more users have never had the money to undertake real promotional campaigns. 

While BSDI won’t discuss what the relative portions of those two million servers are FreeBSD or BSD/OS, it is relatively certain that the majority are running FreeBSD – which has never had the funding to promote its offerings on a level equivalent to what Linux distribution makers have done. The merger will likely put significant cash resources behind the promotion of BSD Unix for the first time. BSDI CEO Johnson said, “everything we’re doing is for the betterment of BSD …  the idea is to promote not BSD/OS, not FreeBSD, not NetBSD, not OpenBSD, but BSD.”

FreeBSD Chief Evangelist Jordan Hubbard said that the merger also leaves the door open to cooperation with the other free BSD variants, NetBSD and OpenBSD. BSDI will be working to bring more third-party applications to BSD, as well as promoting publication of BSD books and developing user groups. 

The fact that many of the technical details of the merger are still undecided leaves the door open to speculation that philosophical differences (or developer egos) may complicate the implementation of the full possibilities of the merger. Still, the merger announcement is a true turning point in the history of BSD Unix, and a much-needed encouraging sign for the platform.