TrustedBSD Extensions Project (fwd)

[Robert Watson]

On Tue, 11 Apr 2000, stanislav shalunov wrote:

> Summary:  Fine, interesting project.  Has nothing to do with Orange
> 	  Book in general and B1 in particular.  I suggest dropping
> 	  all mentions of ``B1'' from the description.
> 
> 	  None of the design criteria is specific to B1, and many
> 	  important objectives of B1 are missed.

I'd tend to disagree with this assertion, and will attempt to address
these differences on a point-by-point basis below.

> I've never been involved in design or have used anything that needed
> Orange Book certification.  However, from what I know about it, the
> project goals are stated in a very misleading way.  I might be
> mistaken in some of those points; if so, please correct me.
> 
> I understand that you do cover significant part of C2 (and, indeed,
> include some features only required starting from B3).
> 
> The objective of B1 is separation of information based on "labels."
> When you print something labeled as "TOP SECRET" out, it has to say
> "TOP SECRET" on the top and on the bottom of each page, or, if you
> override this, it has to leave a trace in the logs.  Are you seriously
> going to implement this?  Is this your design objective?
> 
> Are you seriously going to designate devices and disk slices as
> single-level or muti-level?

The mandatory access control components of TrustedBSD, as with other
trusted operating systems, are intended to address the subject and object
labeling requirements.  Specifically, all user data objects, and subjects,
are assigned security labels which limit the types of accesses that may be
performed.  There are several general questions about the types of
policies that will be enforced--we have had substantial interest in both
confidentiality- and integrity-oriented mandatory policies, and as such I
would expect that both will be supported.  Please see below.

> On the other hand, ACLs and most of the things you're talking about
> are not required.

There is a strong argument that ACLs and a number of the other features
are required by the B1 specification; however, the stated goal of the
project is to include the B1 feature set as part of the target feature
set, not necessarily to have the project be evaluated, nor to limit the
scope of the project to B1 features.  The B1 criteria clearly leave
flexibility in implementation choices, and if additional features make the
security mechanisms more effective, the B1 criteria certainly does not
forbid them. 

> Let's go over the specification and over your objectives.
> 
> 	------------------------------------------------------------
> 
> Your objectives:
> 
> >  Extensible and audited authorization framework for integrating
> >  third-party authorization modules, including general-purpose subject
> >  and object labeling and centralized policy management.
> 
> Not required for B1.
> 
> Not required or explicitly allowed by any of Orange Book specs as far
> as I can see.  Third-party authentication in a trusted environment?
> I think that's contrary to their spirit.

I think you mean authorization here, not authentication.  This feature is
intended to allow TrustedBSD to support multiple policy engines to
providing the required feature set.  In particular, it allows the
seperation of different policy and access control mechanisms in a modular
manner, and their runtime combination to achieve the desired results.
One goal of the project is to make it easier to develop security
extensions on FreeBSD, and ease the maintenance task as the FreeBSD
feature set is expanded.  This generalized authorization framework is
still in the design stages, and probably a good eight or more months away
from completion; however, it is important part of the project goals.

Such a mechanism would also allow the introduction of third party
security extensions that might achieve higher levels of security without
requiring that the extensions include patches to every part of the
operating system.  A specific example may make this goal more clear: a
number of security research organizations (academic, military, commercial)
have developed policy mechanisms.  However, demonstrating the
effectiveness of these policy mechanisms is difficult as it typically
requires wholesale rewriting of extensive pieces of operating system code.
If such policy mechanisms could be dropped in more easily, this would
encourage the development and use of the mechanisms.

The specific example I have in mind is is Domain Type Enforcement,
developed at Trusted Information Systems (now NAI Labs at Network
Associates).  As it stands, such a body of code would involve extensive
changes throughout the operating system source--such changes are difficult
at best to maintain across a changing source based.  Imagine that instead
the OS provided a framework for security extensions, allowing NAI to
distributed only a pluggable module for DTE.

Any formal evaluation would have to be redone to take into account the
changed policy mechanism, but it could rest on the existing code base and
common review process, have an increased chance of correct implementation,
and be far easier to maintain over the product life cycles in both the
operating system and third party security vendor.

While this feature is not required to achieve the specific B1
requirements, in many ways it makes it easier to achieve by forcing the
centralization of security policy code, and allowing easier analysis and
maintenance over the product life cycle.

> >  Fine-grained capabilities for system functions so as to implement
> >  least-privilege and reduce the risks of compromise.
> 
> Not required for B1.  Required for B2.

UNIX was not designed with a TCB in mind--least privilege and careful
allocation of capabilities assists in the delimiting of a TCB in the UNIX
environment.

> >  Mandatory access control for privacy and integrity, allowing FreeBSD
> >  to be used in environments hosting mutually suspicious parties and
> >  multi-level security models.
> 
> Not required for B1.  Required for B3.

On the contrary, I read 3.1.1.4 (Mandatory Access Control) as explicitely
requiring mandatory access control for privacy and integrity.

> >  Access control lists for the file system and other kernel resources
> >  allowing fine-grained and manageable discretionary access control
> 
> Not required for B1.  Required for B3.

Again, I tend to disagree.  I read the discretionary access control
requirements in 3.1.1.1 (Discretionary Access Control) as requiring the
presence of a DAC mechanism that offers the ability to define rights at
the granularity of a user.  ACLs quite clearly fit into this description.
The UNIX file system permissions model cannot allow a user fine
granularity in delegating rights on files, as the group definition is
subject to the administrator and not the individual user.  While it is
possible to imagine  a number of ways to circumvent these limitations,
ACLs are a well-understood way to do this.

> >  Event auditing support 
> 
> Required for B1, but also required for C2.

As you know, each successive certification subsumes the requirements of
the previous level.

> >  single-host modular IDS system to monitor
> >  security events and notify administrators in the event of
> >  irregularities
> 
> Can't find anything in Orange Book that looks like an IDS.
> They have the concept of special persons dedicated to reading
> all the logs files, it seems.

IDS is a relatively new field; that said, I think automatic processing of
event audit data is a natural fit with a trusted operating system.  In
fact, a great deal of the literature I have in hand strongly recommends
some sort of automated audit log reduction.  Again, targetting the B1
criteria does not require that we limit ourselves to only the explicitely
mentioned feature set.

> Their specification (this is from
> <URL:http://csrc.nist.gov/secpubs/rainbow/std001.txt>, and I only
> quote relatively short passages):
> 
> # 3.1 CLASS (B1): LABELED SECURITY PROTECTION
> # 
> # Class (B1) systems require all the features required for class (C2).
> 
> You're missing even C2, because C2 is a certification of a combination
> of hardware and software.

Evaluation takes place in the context of a complete computer system.
However, if you read the announcement and documentation carefully, the
project targets the feature set and not necessarily certification itself.
That said, I expect that a set of recommendations for appropriate hardware
would make a great deal of sense.  And if someone would like to sponsor
evaluation, selection of specific hardware would become more important.
As evaluation is a costly process, and no sponsors have come forward at
this point, I'd have to say I'll be pushing that towards the bottom of the
list, and I imagine the other developers will also :-).

> # In addition, an informal statement of the security policy model,
> # data labeling, and mandatory access control over named subjects and
> # objects must be present.
> 
> Development is under way, but security policy model is not described.

Improved documentation is underway also, and will be put online in the
near future.  The design of the generalized policy mechanism described
earlier is also underway, and I hope to provide more detailed information
in a couple of months.

> # The capability must exist for accurately labeling exported
> # information.
> 
> Not a stated objective.  I hope you're not implementing this, because
> you would better spend your programming time on something useful.

Associated I/O with labeling makes sense--you can imagine a number of ways
in which this might be done.  Spending time modifying the print spooler is
not high on the list of objectives, but presumably would be relatively
relaxing compared to regression testing access control mechanisms.
Clearly indicating which I/O devices are associated with various security
properties is important in a secure system.

The list of targets on both the TrustedBSD.org front page, and in the
introduction, is more of an executive summary than an architecture
document, and as I have mentioned, is underway.

> # 3.1.1 Security Policy
> #      3.1.1.1 Discretionary Access Control
> # 
> #                The TCB shall define and control access between named
> #                users and named objects (e.g., files and programs) in
> #                the ADP system.  The enforcement mechanism (e.g.,
> #                self/group/public controls, access control lists)
> #                shall allow users to specify and control sharing of
> #                those objects by named individuals, or defined groups
> #                of individuals, or by both, and shall provide
> #                controls to limit propagation of access rights.
> 
> I.e., basic Unix permissions.  Already in any Unix.

There is a strong argument that UNIX file permissions do not fully meet
these requirements; even if they did, there is a strong argument that
fine-grained ACLs fit the description better, and are useful in other
areas of a trusted operating system.

> #           3.1.3.1.2 System Integrity
> #                      Hardware and/or software features shall be
> #                      provided that can be used to periodically
> #                      validate the correct operation of the on-site
> #                      hardware and firmware elements of the TCB.
> 
> How shall you do this?

This issue has not yet been addressed, and I would welcome discussion
concerning whether or not it should be addressed by the project in absence
of a proposed hardware configuration. :-)  As the TCB relies on memory
protection and controlled transfer of control between hardware maintained
partitions, I imagine it would be possible to construct verification
software to indicate if they are generally behaving correctly.  Presumably
reseaching how and to what extent this is addressed by other evaluated
systems would be a good place to start.

> #      3.1.3.2 Life-Cycle Assurance
> #           3.1.3.2.1 Security Testing
> #                      The security mechanisms of the ADP system shall
> #                      be tested and found to work as claimed in the
> #                      system documentation.  A team of individuals
> #                      who thoroughly understand the specific
> #                      implementation of the TCB shall subject its
> #                      design documentation, source code, and object
> #                      code to thorough analysis and testing.  Their
> #                      objectives shall be: to uncover all design and
> #                      implementation flaws that would permit a
> #                      subject external to the TCB to read, change, or
> #                      delete data normally denied under the mandatory
> #                      or discretionary security policy enforced by
> #                      the TCB; as well as to assure that no subject
> #                      (without authorization to do so) is able to
> #                      cause the TCB to enter a state such that it is
> #                      unable to respond to communications initiated
> #                      by other users.  All discovered flaws shall be
> #                      removed or neutralized and the TCB retested to
> #                      demonstrate that they have been eliminated and
> #                      that new flaws have not been introduced.  (See
> #                      the Security Testing Guidelines.)
> 
> I.e., any remote DoS means no B1.  Where is your team?

Again a point you at the word ``target'', and greatfully accept your offer
to assist in penetration testing and development. :-)  I submit that the
code doesn't come from nowhere, and recommend the developers as a source
of knowledge about the TCB design and implementation.  Also, this appears
to refer more to a formal bug reporting, correction, and verification
cycle than a loss of certification.  However, if others have experience in
this area, I'd be glad to hear about it.

> #           3.1.3.2.2 Design Specification and Verification
> #                      An informal or formal model of the security
> #                      policy supported by the TCB shall be maintained
> #                      over the life cycle of the ADP system and
> #                      demonstrated to be consistent with its axioms.
> 
> How are you going to be compliant with this?

There has been extensive literature on the topic of formal models for
security policies, including lattice MAC models, and so on.  The security
model currently being implemented in our MAC module is a Bell-La Padula
confidentiality model.  We're also extremely interested in implementing
integrity-oriented models, such as those described by Biba.  In the
presence of a pluggable policy module mechanism, the burden of verifying
the policy's correctness lies with the module maintainer.

> # 3.1.4 Documentation
> #      3.1.4.1 Security Features User's Guide
> # 
> #                A single summary, chapter, or manual in user
> #                documentation shall describe the protection
> #                mechanisms provided by the TCB, guidelines on their
> #                use, and how they interact with one another.
> 
> This goes to the contrary with Unix tradition of separation of man
> pages.  Are you going to lump all your docs into one page just to
> satisfy this?

I'd actually prefer a comprehensive security architecture document,
myself.

> Finally, design specs are absent even though code already exists.
                                  ^ from the web site

TrustedBSD is a work in progress.  Substantial progress has been made in
its implementation, but there remains much to do.  I welcome those
interested in working on the project to do so.

> I don't see why you decided to mention B1.  I again suggest that you
> drop this word and adhere to a different specification (POSIX.1e) or
> to no specification at all (where there's none).

The Orange Book criteria are useful in a number of ways.  First, they
identify an explicit set of feature requirement, requirements that are
widely recognized to be useful in a variety environments.  There seems to
be a fairly close fit between the feature set offered by TrustedBSD and
the B1 criteria--go any lower on the scale and the features are far in
excess of the requirements; go any higher and you lose out due to the
formal verification requirements.  Clearly there are some limitations--the
hardware requirements aren't a close fit with a software-driven project,
etc.  With all this in mind, the identification of the B1 evaluation
criteria as a target should bring to mind the appropriate types of
features for an informed audience--mandatory access control, discretionary
access control, fine-grained auditing, and so on.

  Robert N M Watson 

robert at fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services


To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message