by Jeffrey Carl
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.