TrustedBSD Extensions Project

[stanislav shalunov]

> From: Robert Watson <robert at cyrus.watson.org>
> On Tue, 11 Apr 2000, stanislav shalunov wrote:

> > 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.

I interpret 3.1.1.3.2 as requiring you to (be able to) put
(machine-readable equivalent of) something like SINGLE_LEVEL,
TOP_SECRET into (something like) disklabel.  This seems to be distinct
from mandatory access control.

> There is a strong argument that ACLs and a number of the other features
> are required by the B1 specification;

I interpret 3.1.1.1 ("The enforcement mechanism (e.g.,
*self/group/public controls*, access control lists) shall allow
users...", emphasis mine) as saying unix permissions are sufficient.
This assumes that the comma means OR.

One might agrue that the comma over there means AND not OR.  In my
opinion, this interpretation would render the whole sentence
meaningless, because once you have ACLs, unix permissions are not
necessary.

I wish they were more clear and not require such Talmudic studies to
understand what they want to say.

> 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.

I would word it differently:  "The design goals of TrustedBSD do not
fit well into Orange Book outdated scheme."

> 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.

Yes, it's only higher in the hierarchy you're required to not include
unnecessary parts.  We understand, however, that amount of code in the
system is crucial and that complexity is the main enemy of security.

> > >  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.

You are right, sorry.

> This feature is intended to allow TrustedBSD to support multiple
> policy engines to providing the required feature set.
[Motivation for having framework for plugging third-party
authentication modules.]

I'm not questioning the motivation.  I don't discuss whether it's good
or bad to have it.  All I'm saying that to me this looks like
something contrary to the spirit of Orange Book.

> 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.

Again, I'm all for implementing least privilege principle.
I just mentioned that it's not required for B1.

> > >  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.

My mistake.  Thanks for pointing this out to me!

> > >  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.

See above.  Only starting from B3 does it state that self/group/others
is not enough.

> > >  Event auditing support 
> > Required for B1, but also required for C2.
> 
> As you know, each successive certification subsumes the requirements of
> the previous level.

I was just pointing out how TrustedBSD doesn't fit their scheme.

> > 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.

Again, I'm not questioning the validity of the concept of IDS and
usefulness of an IDS.  But Orange Book doesn't require it.

> 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.

But the feature set includes things that are only relevant to specific
hardware!  What was that C2-certified Windows version on hardware
without a NIC?

I can easily meet A2 requirements by removing all hardware.
Absent system is very secure:  The security model is simple,
the code contains no bugs (because there's no code), there are no ways
to steal information or circumvent information protection or have any
covert channels, etc.  A cubic meter of vacuum is a very secure
computer system indeed.

The more hardware you add, the more complicated task you're facing.
Backups, floppies, Jaz drives, parallel port, etc., all need to be
very carefully scrutinized.

You can't designate I/O channels with levels of sensitivity if you
don't know what I/O channels you have!

> 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 :-).

Do you want certification?  Do you need it for your network?
Do you know anyone who does?  If somebody in the U.S. government wants
to use trusted BSD, why don't they come forward and say they'll
sponsor evaluation and certification?

> 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.

How can you implement security mechanisms without security model?

> There is a strong argument that UNIX file permissions do not fully meet
> these requirements;

(Covered.)

> 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.

I don't question the need for ACLs.  That's the most interesting for
me of the design goals.  I'd sure like to say that user syslog can
only append to log files, and user newsyslog can have full write
access, and so on.

But B1 doesn't require it.

> > #           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.

What if your disk controller goes bad and decides to write a block of
TOP SECRET information onto CLASSIFIED hard drive once in every ten
thousand requests?

You would need to have a trusted disk controller that has extensive
self-checks.  Do you know of such disk controllers in the market for
PCs?  I don't.

> > #           3.1.3.2.1 Security Testing
> > 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.

After re-reading the section I see that it implies that any
*localhost* DoS is incompatible with B1.  This is something very
difficult to tackle.  Unix has not been designed initially to resist
either localhost root exploits or DoS.  While the root exploits area
is relatively well-researched and is being handled for last 15 years
or so, we still have an exploit now and then.

DoS is much harder to prevent than root exploits.  Even remote DoS
attacks are hard to prevent (I'll soon publish a generic remote DoS
that crashes FreeBSD in particular).  But localhost DoS attacks have
never been seriously addressed.  Decades of work are probably required
to make Unix somewhat resistant to them.

> 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.

I'm not familiar with the literature you're alluding to, but the
explanation is sufficient for me.

> In the presence of a pluggable policy module mechanism, the burden
> of verifying the policy's correctness lies with the module
> maintainer.

So, what exactly could be evaluated (if a sponsor came forth)?

> > 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.

Who, other than U.S. government users, want Orange Book certification
or feature set?  I don't think I need it.

Just think about it:  Colored windows, and you can only cut-and-paste
between windows of the same color.  How shall this work under X?
How shall you identify rogue applications that mess with colormaps?

> 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;

Software requirements are in excess anyway.

> go any higher and you lose out due to the formal verification
> requirements.

Well, B2 adds mostly just covert channel analysis.  Formal
verification is only required starting from A1.  (It is true that
formal verification of compliance with security model during life
cycle is required, but that shouldn't be too hard.)

	------------------------------------------------------------

I'm not convinced.  I hope the developers are.  

As I see it, what you're trying to do is interesting and needed, but
it's not in the Orange Book.  System administrators need penetration
resistance more than labelling data, and Orange Book gets it all
backwards.

-- 
stanislav shalunov,	WHPD,	shalunov at att.com	732-576-3252
12:40PM  up 178 days,  2:03, 6 users, load averages: 0.04, 0.01, 0.00

Going to church does not make a person religious, nor does going to
school make a person educated, any more than going to a garage makes a
person a car.
To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message