On Wed, 20 Apr 2005, Michael A. Koerber wrote:
> 1. Currently FreeBSD (or any other BSD) doesn't seem to be on the list
> of approved OS's for classified processing. I'm trying to obtain
at
> least local approval, but I don't speak the "security
language" too
> well. Any help would be greatly appreciated.
Currently, FreeBSD "out of the box" has not been publically certified
by
any known vendors or institutions to be used for multi-level or
compartmentalized processing. However, it is used in those sorts of
environments, and FreeBSD is used extensively in products that have been
certified (such as routers). This is because, traditionally, the role of
certification has been something product vendors do, and the scope for
direct vendors of FreeBSD as an OS is limited, compared with the scope of
vendors selling products that integrate FreeBSD. There has been interest,
but because of previously missing feature sets, the cost to do a
certification has been seen as too high by the interested parties. We've
been working hard to remedy the missing feature concern, and in 6.x, due
out later this year, we should be pretty close to feature complete. More
below on that.
A final comment: because FreeBSD tends to be the foundation of custom
solutions, we often don't know about some of the more interesting uses of
FreeBSD in the military environment. As such, we may in fact not be the
right people to tell you about existing use.
> 2. The unix's that are approved are Solaris and Redhat/Fedora. I have
> reviewed the "PL1 Checklists" and it seems to me that
Redhat/Linux might
> be the closest set of requirements, so I'm working off that.
Current releases of Linux don't have all the required features, such as a
lack of a proper audit implementation.
> 3. I've "mapped" most of the requirements to FreeBSD (basic
unix
> stuff).
>
> 4. The major sticking point today is "Accesses to Security-Relevant
> Objects".
Our MAC pieces start the address this, and do a fairly reasonable job for
the kernel, especially on 6.x. 5.x doesn't have as complete object
coverage. It's possible to backport them, and at least one person has,
but it breaks several kernel ABIs so will break otherwise functional 5.x
kernel modules, hence our not backporting them yet. For example, in 6.x,
System V IPC objects are covered by MAC, but not in 5.x.
> a. Under Redhat the requirement is "Implement Snare" or
"Implement LauS
> (Linux Auditing System".
>
> b. The Solaris equivalent requirement seems to be set up of the Basic
> Security Model "BSM".
>
> I don't see either of these packages ported to BSD. What is the BSD
> approach to meeting the (logging) requirements provided by the above
> packages? I thought that MAC might be the answer, but I see nothing
> about logging "events" in the manual.
We're about to import OpenBSM, an open source implementation of BSM audit
for FreeBSD in the next few months. However, the dates are getting a bit
tight to get it in for 6.0 as a production feature. We hope to be able to
get it in as an experimental feature for 6.0, and production for 6.1.
Since certification normally occurs alongside development, that might not
be a bad time to begin certification, if it were going to happen.
I'm not sure what environment you're looking at, but the notions of
"certification" and "acreditation" are very complicated.
Usually there
are two steps: (1) documenting a set of requirements, and (2)
demonstrating that the system meets the requirements. Selection of
requirements turns out to be a very flexible process, and all kinds of
systems are used for classified data under very weak requirements. Audit
is often, but not always, required, but MAC is typically not. Specific
certifications vary hugely here, but a good starting point is the CAPP
common criteria certification. With the exception of having integrated
audit support, which is coming very shortly, FreeBSD should meet 99% of
CAPP requirements as EAL3, and with documentation and cleanup, should
reach them at EAL4.
The strong requirements typically come in at security boundaries, such as
guards between networks, or in the processing of compartmented data. In
those environments, certifcations vary a lot, but a reasonable starting
point is the LSPP common criteria certification. Once you have CAPP,
FreeBSD is also very close to LSPP, especially if you select a subset of
behavior (i.e., omit sendmail or such).
The TrustedBSD Project (http://www.TrustedBSD.org/) is where most of this
work is occuring, with code being brought back into FreeBSD at useful
intervals as it matures.
Robert N M Watson