TrustedBSD Extensions Project (fwd)
Robert Watson
robert at cyrus.watson.org
Tue Apr 11 22:18:32 GMT 2000
Received this message privately (wasn't approved for bugtraq) but thought
that it might make a good point for discussion.
Tomorrow afternoon, once I recover from the monsoon of TrustedBSD-related
email, I'll be posting a current status report on components of the
TrustedBSD project.
In the mean time, a number of book/paper references have been posted on
the mailing list--it would probably be nice to have a bibliography online,
so I'll collect them and put them on the web page at some point in the
next few days. It also looks like securityfocus.com is archiving both of
the TrustedBSD mailing lists, for those interested.
---------- Forwarded message ----------
Date: Tue, 11 Apr 2000 17:12:49 -0400 (EDT)
From: stanislav shalunov <shalunov at att.com>
To: bugtraq at securityfocus.com
Cc: rwatson at FreeBSD.org
Subject: Re: TrustedBSD Extensions Project
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'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?
On the other hand, ACLs and most of the things you're talking about
are not required.
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.
> 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.
> 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.
> 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.
> Event auditing support
Required for B1, but also required for C2.
> 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.
------------------------------------------------------------
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.
# 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.
# 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.
# 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.
# The discretionary access control mechanism shall,
# either by explicit user action or by default, provide
# that objects are protected from unauthorized access.
# These access controls shall be capable of including
# or excluding access to the granularity of a single
# user. Access permission to an object by users not
# already possessing access permission shall only be
# assigned by authorized users.
I.e., umask 077. Easy to add to any Unix.
# 3.1.1.2 Object Reuse
#
# All authorizations to the information contained
# within a storage object shall be revoked prior to
# initial assignment, allocation or reallocation to a
# subject from the TCB's pool of unused storage
# objects. No information, including encrypted
# representations of information, produced by a prior
# subject's actions is to be available to any subject
# that obtains access to an object that has been
# released back to the system.
I.e., zero-filled pages. Already in any Unix.
# 3.1.1.3 Labels
[Lots of junk.]
# The ADP system administrator shall be able
# to specify the printable label names
# associated with exported sensitivity
# labels. The TCB shall mark the beginning
# and end of all human-readable, paged,
# hardcopy output (e.g., line printer
# output) with human-readable sensitivity
# labels that properly* represent the
# sensitivity of the output. The TCB shall,
# be default, mark the top and bottom of
# each page of human-readable, paged,
# hardcopy output (e.g., line printer
# output) with human-readable sensitivity
# labels that properly* represent the
# overall sensitivity of the output or that
# properly* represent the sensitivity of the
# information on the page. The TCB shall,
# by default and in an appropriate manner,
# mark other forms of human- readable output
# (e.g., maps, graphics) with human-
# readable sensitivity labels that properly*
# represent the sensitivity of the touput.
# Any override of these marking defaults
# shall be auditable by the TCB.
# _____________________________ * The hierarchical classification
# component in human-readable sensitivity labels shall be equal to the
# greatest hierarchical classification or any of the information in
# the output that the labels refer to; the non-hierarchical category
# component shall include all of the non-hierarchical categories of
# the information in the output the labels refer to, but no other
# non-hierarchical categories.
Sounds like fun?
# Identification and authentication data shall be used
# by the TCB to authenti- cate the user's identity and
# to ensure that the security level and authorization
# of subjects external to the TCB that may be created
# to act on behalf of the individual user are dominated
# by the clearance and authorization of that user.
Do you have your clearance? No clearance--no access.
# 3.1.2 Accountability
# 3.1.2.1 Identification and Authentication
[Must have /etc/master.passwd or equivalent.]
# 3.1.2.2 Audit
[Must have accounting and log of file opens and deletes.]
# 3.1.3 Assurance
# 3.1.3.1 Operational Assurance
# 3.1.3.1.1 System Architecture
[Must execute kernel in privileged mode.]
# 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?
# 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?
# 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?
# 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?
# 3.1.4.2 Trusted Facility Manual
# 3.1.4.3 Test Documentation
#
# The system developer shall provide to the evaluators
# a document that describes the test plan, test
# procedures that show how the security mechanisms were
# tested, and results of the security mechanisms'
# functional testing.
"Shall provide the evaluators..."
# 3.1.4.4 Design Documentation
#
# Documentation shall be available that provides a
# description of the manufacturer's philosophy of
# protection and an explanation of how this philosophy
# is translated into the TCB. If the TCB is composed
# of distinct modules, the interfaces between these
# modules shall be described. An informal or formal
# description of the security policy model enforced by
# the TCB shall be available and an explanation
# provided to show that it is sufficient to enforce the
# security policy. The specific TCB protection
# mechanisms shall be identified and an explanation
# given to show that they satisfy the model.
Finally, design specs are absent even though code already exists.
------------------------------------------------------------
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).
--
stanislav shalunov, WHPD, shalunov at att.com 732-576-3252
5:08PM up 177 days, 6:31, 6 users, load averages: 0.02, 0.04, 0.00
The nice thing about standards is that there are so many of them to
choose from. -- Andrew S. Tanenbaum
To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message
More information about the trustedbsd-discuss
mailing list