Meeting Security Requirements with FreeBSD

[Robert Watson]

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