Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 14 Oct 1997 09:56:38 -0600 (MDT)
From:      Wes Peters <softweyr@xmission.com>
To:        Christopher Petrilli <petrilli@amber.org>
Cc:        security@freebsd.org
Subject:   Re: C2 Trusted FreeBSD? 
Message-ID:  <199710141556.JAA10419@obie.softweyr.ml.org>
In-Reply-To: <199710132110.RAA29578@dworkin.amber.org>
References:  <199710132110.RAA29578@dworkin.amber.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Christopher Petrilli writes:
 > It is not "mandatory," however the following paragraph exerpted from the 
 > TCSEC does make it clear that the exisintg group mechanism is NOT 
 > acceptable:
 > 
 >      "The access controls shall be capable of including or excluding 
 > access
 >       to the granulairty of a single user."
 > 
 > This exclusion part is what makes it very difficult.  You must be capable 
 > of giving access to everyone BUT a specific user.  While theoretically I 
 > guess you could do it by managing billions of sepereate groups, I think 
 > it would fail none the less because of practical enforcement concerns.

Nope.  The Sun C2 security system used only group controls.  This is the
U.S. government, there are *no* concerns about practical enforcement.
In their view, if any mechanism is provided, their slaves can be beaten
into writing procedures that will correctly use the supplied mechanism,
clumsy as it may be.


 > THat having been said, there is one other requirement that would need to 
 > be addressed:
 > 
 >      * Object Reuse (2.2.1.2)
 > 
 > THis is defined as follows:
 > 
 > "All authorizations to the information contained iwthin 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."
 > 
 > Basically, we need to purge all memor when it is allocated, or 
 > deallocated.

Has to be deallocated, unless you want to maintain ownership credentials
of the deallocated pools.  The act of returning a block of memory to the
"free" pool changes its ownership.  There is an existing standard for
reclaiming memory in C2 systems.  If I remember correctly, you have to
overwrite each bit with successive 1 and 0 for 100 cycles.  This is
pretty cpu intensive, but can be done pretty easily by modify sbrk and
friends.  I guess in the post 2.2 world, it would be munmap that gets
mangled, right?

 > Other than that, it's mostly documentation, and audit.  I would really 
 > prefer to do an ACL extension to the file system, as I think it's useful 
 > as it is :-)

Agreed.  A simple but useful ACL system, like the one in HP-UX, is a
very nice system administration tool.  It also makes for amusing jokes,
where you can put an ACL on a user's file so he can read it but not
write it.  ;^)

-- 
          "Where am I, and what am I doing in this handbasket?"

Wes Peters                                                       Softweyr LLC
http://www.xmission.com/~softweyr                       softweyr@xmission.com



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710141556.JAA10419>